-
Notifications
You must be signed in to change notification settings - Fork 645
spacetime init rewrite
#3366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
spacetime init rewrite
#3366
Conversation
c022d34 to
ea0f0f7
Compare
ea0f0f7 to
e536cc3
Compare
10f14ee to
cc118cc
Compare
…s/SpacetimeDB into drogus/spacetime-init
Signed-off-by: John Detter <[email protected]>
…s/SpacetimeDB into drogus/spacetime-init
…s/SpacetimeDB into drogus/spacetime-init
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've tested
- Fixed the --server-only bug which prevented generating the module code
- Finished testing the Unity tutorial for both rust and C# modules up to the spacetime generate ... part
- Test Unreal tutorial with both C# and rust up to the spacetime generate ... part
- Fix the issue with Cargo.toml in the rust quickstart
- Test rust module quickstart
- Test C# module quickstart
- Test typescript module quickstart
There are a few code things that I would probably change but I think we can do those as follow-up PRs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, John and I have thoroughly tested and fixed small bugs. There are two remaining items that are pretty gnarly in this version:
- We scoop up the slop from all over the repo, and we realllllly should change that to be a straightforward copy of future
/templatesdirectory - We need a better gameplan for ensuring that the templates locally depend on SpacetimeDB if you have the repo checked out, but use a package manager/versioning scheme if you copy them as a template. It's pretty slapdash right now, but it kinda works. We should make it better (standardized).
I'm okay to do these things later.
This is a draft of the new functionality for `spacetime init`. In order to run it with built-in templates you have to set the path to the config file: ``` export SPACETIMEDB_CLI_TEMPLATES_FILE=crates/cli/.init-templates.json ``` In the future it will fetch the list from GH. A few notes: * the previous functionality of `spacetime init` does not work at the moment * the code needs a bit more cleanup and tests before merging * there is a bit of a mix in how we generate empty server and client projects. For Rust we use the existing way of generating. For TypeScript we clone an empty project from the repo. I wanted to play with both ways of doing things, and I'm still not sure which is better. Generation in Rust means that the generated code will match the CLI version and not necessarily whatever is in Git. On the other hand, for the builtin templates we will be fetching the newest version from GH, which I guess might also not what we want, ie. we probably want only stable templates. More discussion is needed here * we use `spacetimedb` directory for the server files * I don't particularly like the inability to disable interactive mode easily. We discussed disabling it by default if all of the required arguments are passed, but I don't think it's feature proof. For example, if someone relies on a non-interactive mode, and we add a new required argument, instead of printing a message `missing --foo`, we will automatically launch interactive mode, which is harder to debug. That's why I think I'd prefer to implement `--non-interactive` argument * it's kind of hard to keep the legacy behaviour. If you don't pass any arguments, we go into interactive mode. In the legacy version, we would print required arguments. If someone passes `--lang` or `--project-path` explicitly, I guess we could run the legacy workflow, but not sure if it's worth it, as the command was marked as unstable anyway * the project path defaults to the project name, but I think we should probably replace change whitespaces to dashes, or at least ask for the project path with the project name being the default (or both) --------- Signed-off-by: Tyler Cloutier <[email protected]> Signed-off-by: John Detter <[email protected]> Co-authored-by: = <[email protected]> Co-authored-by: Tyler Cloutier <[email protected]> Co-authored-by: Tyler Cloutier <[email protected]> Co-authored-by: John Detter <[email protected]>
This is a draft of the new functionality for
spacetime init. In order to run it with built-in templates you have to set the path to the config file:In the future it will fetch the list from GH.
A few notes:
spacetime initdoes not work at the momentspacetimedbdirectory for the server filesmissing --foo, we will automatically launch interactive mode, which is harder to debug. That's why I think I'd prefer to implement--non-interactiveargument--langor--project-pathexplicitly, I guess we could run the legacy workflow, but not sure if it's worth it, as the command was marked as unstable anyway