# Description of Changes
This reverts commit 53f692dec6 (#3568)
That PR broke the build if any of the directories used as templates are
not clean. It spammed lots of errors like:
```
error: `C:\Users\boppy\clockwork\SpacetimeDB\crates\cli/.templates/parent_parent_sdks_csharp_examples~_quickstart-chat_client/obj~/Debug/net8.0/client.pdb` wasn't a utf-8 file
--> C:\Users\boppy\clockwork\SpacetimeDB\crates\cli/.templates/parent_parent_sdks_csharp_examples~_quickstart-chat_client/obj~/Debug/net8.0/client.pdb:0:49
|
error: `C:\Users\boppy\clockwork\SpacetimeDB\crates\cli/.templates/parent_parent_sdks_csharp_examples~_quickstart-chat_client/obj~/Debug/net8.0/ref/client.dll` wasn't a utf-8 file
--> C:\Users\boppy\clockwork\SpacetimeDB\crates\cli/.templates/parent_parent_sdks_csharp_examples~_quickstart-chat_client/obj~/Debug/net8.0/ref/client.dll:0:3
|
error: `C:\Users\boppy\clockwork\SpacetimeDB\crates\cli/.templates/parent_parent_sdks_csharp_examples~_quickstart-chat_client/obj~/Debug/net8.0/refint/client.dll` wasn't a utf-8 file
--> C:\Users\boppy\clockwork\SpacetimeDB\crates\cli/.templates/parent_parent_sdks_csharp_examples~_quickstart-chat_client/obj~/Debug/net8.0/refint/client.dll:0:3
```
# API and ABI breaking changes
None.
# Expected complexity level and risk
1
# Testing
- [x] `cargo build` passes on my repo now, which it wasn't before this
commit
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
We technically don't need to `git ls-files` when getting the CLI
templates because when we compile the release builds we work with a
clean git clone, thus it's unlikely any untracked files will be created
in the templates directory.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
- [x] I've manually checked that the init command still generates the
templates properly
# Description of Changes
When building under Nix, Git metadata is not available within the
sandbox, as we use `lib.cleanSource` on our source directory. This is
important because it avoids spurious rebuilds and/or determinism
hazards.
The build was broken due to our new `spacetime init` template system
accessing Git metadata in the CLI's build.rs
to filter out non-git-tracked files from the templates. The Flake
sandbox does this automatically (even without `lib.cleanSource`!), so
when building under Nix it's unnecessary to do twice. (I remain
unconvinced that it's necessary to do in non-Nix builds either, as CI
builds should have a clean checkout and local dev builds don't need
clean templates, but the behavior was already in master and I didn't
feel comfortable removing it.)
As an enhancement, I've also found a Nix-ey way to embed our Git commit
hash in builds. Previously, builds under Nix had the empty string
instead of a commit hash, because we included the `git` CLI tool but
scrubbed the necessary metadata. Now, we inject an environment variable
from the Nix flake, and don't make the `git` CLI tool available at all.
This has the convenient upside of allowing Nix builds to reference
`dirtyRev` in builds with a dirty worktree, which should reduce
confusion.
# API and ABI breaking changes
N/a
# Expected complexity level and risk
3? I didn't have a strong understanding of what the CLI build script was
doing, and to what extent it was doing things intentionally versus for
convenience. As such, it's possible that I've inadvertently damaged
something load-bearing.
# Testing
- [x] Built with `nix build`, ran `spacetime init`, chose the
`basic-rust` template, and got a reasonable-looking template
instantiation.
- [ ] Hopefully we have automated tests for this?
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 <cloutiertyler@users.noreply.github.com>
Signed-off-by: John Detter <4099508+jdetter@users.noreply.github.com>
Co-authored-by: = <cloutiertyler@gmail.com>
Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
Co-authored-by: Tyler Cloutier <cloutiertyler@aol.com>
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>