Fix Nix build by not using Git in Cargo build scripts #3551
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
cloutiertyler
approved these changes
Oct 31, 2025
Contributor
cloutiertyler
left a comment
cloutiertyler
left a comment
There was a problem hiding this comment.
This seems fine to me. The CI will also have tested that it can build on non-nix. I am going to approve this, but yeah I think we should rip all this out at some point.
github-merge-queue
bot
removed this pull request from the merge queue due to no response for status checks
bfops
pushed a commit
that referenced
this pull request
Nov 6, 2025
…ts (#3551) # 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?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of Changes
When building under Nix, Git metadata is not available within the sandbox, as we use
lib.cleanSourceon our source directory. This is important because it avoids spurious rebuilds and/or determinism hazards.The build was broken due to our new
spacetime inittemplate system accessing Git metadata in the CLI's build.rsto 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
gitCLI tool but scrubbed the necessary metadata. Now, we inject an environment variable from the Nix flake, and don't make thegitCLI tool available at all. This has the convenient upside of allowing Nix builds to referencedirtyRevin 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
nix build, ranspacetime init, chose thebasic-rusttemplate, and got a reasonable-looking template instantiation.