search

quantified-uncertainty / squiggle

An estimation language
https://squiggle-language.com
MIT License
152 stars 23 forks source link

Support at least one more model content type #1820

Open berekuk opened 1 year ago

berekuk commented 1 year ago

I want to do this early to figure out UI and to prove that DB and GraphQL schemas work.

Right now we have only one content type, SquiggleSnippet.

The second one could be either SquiggleRepo (multi-file, requires imports and UI for editing), or SquiggleNotebook (requires UI for editing cells).

OAGr commented 1 year ago

I'm pretty nervous about dividing up things into several workflows. Like, SquiggleSnippet vs. SquiggleRepo. Supporting each could be a fair bit work, I generally like to begin focusing on a very few that are particularly flexible.

Maybe for Snippet vs. Repo, we could have some flexible combination? Like, it's a repo, but it's easy to get started with and over-time build up upon.

berekuk commented 1 year ago

Like, SquiggleSnippet vs. SquiggleRepo.

Yes, in this case, I agree. It's just an example I used initially, based on the parallel with Github's repo vs gist. But in our case we could just support multi-file models in all cases.

I've also become less sure that "notebook" is a content type, and not a separate entity (/users/{username}/notebooks/{slug}). This depends on whether notebooks will export any variables, or will be used only for representation.

Still, I think we need the support for other content types, e.g. for the future Guesstimate (and possibly Metaforecast) support, so this issue is still necessary.