This makes it possible to evaluate crane in a nixos test without network
as well as allow to backup all fetched input derivations properly in a
binary cache, whereas fetchGit will fallback to downloading from a
repository, which also requires a `git` binary to be present.
Co-authored-by: Ivan Petkov <ivanppetkov@gmail.com>
* Turns out it is much faster to build up one big regex of the
references to remove and invoking `sed` just once than it is to invoke
it once per reference
* Define a new installation mode which symlinks identical artifacts
against a directory of previously generated ones
* This allows for linear space usage in the Nix store across many
chained derivations (as opposed to using a zstd compressed tarball
which uses quadratic space across many chained derivations)
* This new installation mode is the new default for all cargo based
builds. The previous behavior is still available by setting
`installCargoArtifactsMode = "use-zstd";` on a derivation
* `buildPackage` will continue to use zstd compressed tarballs while
building dependencies (unless either of `cargoArtifacts` or
`installCargoArtifactsMode` is defined, in which case they will be
honored)
* Using substitutions for build hooks is a great way to ensure the
necessary utility is present without making the caller supply it to
the builder, except it makes things confusing when applying overrides
* For example, the `installFromCargoBuildLog` hook was inadvertently
ignoring any `cargo` overrides applied to the entire `lib`
instantiation
* By removing all explicit substations we also side step the issue of
trying to select the correct build/host/target version of the tool and
use whatever is present in the build environment
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.
* This allows for fewer assumptions about the project structure
* The old behavior can easily be brought back by setting `cargoExtraArgs
= "--workspace";` in any derivation
* 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)
* This hook was never a great implementation to begin with since it
would simply search the cargo artifacts directory for binaries and
libraries to install
* This isn't really great since if we have multiple builds (say one with
debug artifacts, one with release artifacts) it isn't exactly clear
which artifacts would get installed (or which will get clobbered).
* Now that we have installFromCargoBuildLogHook we can simplify the
options a bit and only have one main installation method. The caller
can always provide their own if they wish
