This is done to avoid breaking builds by including puts happen to have
setup-hooks which try to claim the configure phase (such as `cmake`).
The old behavior can be brought back by setting `configurePhase = null;`
on the derivation.
* Seems like cargo-audit only needs a `Cargo.lock` file and an advisory
database to run, so we can filter the inputs down even further to
avoid rebuilds and file copying into the Nix sandbox
* When Nix fetches a git repo it will only look for the specified
revision only starting from the main branch (apparently fetching
arbitrary revisions from a repository has some security implications)
* If a ref (i.e. branch or tag) is not specified, Nix will only fetch
the repo's main branch
* To remedy this we will supply Nix with the branch or tag (if specified
in the Cargo.lock) to help it find the specified revision
* If cargo does not specify a branch or tag for us, we'll set `allRefs =
true` so that Nix can try fetching all possible branches and tags
before trying to check out the locked revision
* Seems like cachix is still pushing the results up to the cache, we
might as well get use of downloading the (empty) results rather than
having to pull down the intermediary binaries and running them each
time
* Previously all build hooks were instantiated in a single
`callPackages` call which led to several issues:
- changes via `lib.overrideScope'` were ignored because the build
hooks were only ever instantiated with the nixpkgs instance of our
flake (not whatever overlays the caller may have made)
- the pkgs splicing was not done quite right, meaning when we pull in
the build hooks as nativeBuildInputs the splicing wasn't picking up
the overridden versions of `cargo` but was instead trying to
recompile the nixpkgs version each time
* Similarly rename `installCargoTargetDirHook` to
`installCargoArtifactsHook`
* The intention is to highlight that "install" implies "copy to output"
and not anywhere else
* Also avoids the potential confusion of "cargo target dir" (location of
cargo's artifacts) with "cargo target" (which is the target
architecture/platform we want cargo to build for)
* There are some edge cases where cargo will allow a lib.rs file to be
present but not a main.rs (e.g. a binary cannot be called "examples",
which will happen if the crate is called that and a main.rs file is
present)
* By default we pass everything through to the actual derivation itself,
but some internal parameters don't show up as environment variables
directly (or rather do not need to)
* In an effort to keep the build environment as lean as possible, we can
do some clean up (e.g. to avoid invalidating builds if some parameter
changes but is completely ignored/overridden elsewhere)
* Seems like whatever issue was preventing us from evaluating
derivations for other architectures (without actually building them)
has been resolved, and now we can nicely test everything with a single
invocation of `nix flake check`
* `nix flake check` insists on evaluating all outputs for all systems,
which seems to include evaluating build inputs needed for other
systems (which gives us errors like `a 'aarch64-darwin' with features
{} is required to build '...', but I am a 'x86_64-linux'`)
* To work around this we'll move all tests to their own directory
outside of the flake's outputs, and manually invoke a test script to
build them
