* Some tools may try to inspect crate types (e.g. wasm-pack) so it may
be useful to retain the attribute
* In general, the crate-type can influence the project's "structure" so
we should remain faithful to that
* Turns out the `required-features` attribute is only used from hiding
targets from cargo's selection (e.g. do not build unless feature is
enabled) and does not actually influence what features cargo will
enable/build for dependencies
* Hook functions now will accept any relevant arguments and fall back to
our default variables if they are not provided, potentially allowing
them to be adapted externally (without needing more configuration
knobs on our end)
* Reducing the parameter surface area for good measure, zstd compression
works pretty well and it seems redundant to support multiple ways of
copying the target directory around
* `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
* If a derivation is created without a name *and* we cannot infer a name
from a Cargo.toml file, we'll throw a descriptive error message which
hints towards the remediation
* Otherwise nix can throw a pretty obtuse "derivation has no name" error
with no error trace
* Instead of always installing the hook but bailing early based on the
configuration, we will instead only install the hook if the
configuration requests it
* Hopefully the updated name should be more clear that we are inhering
some existing cargo artifacts and NOT inheriting something like
CARGO_BUILD_TARGET which refers to the host target being built
* This allows us to copy over the cargo artifacts as early as possible
so that any other phases/hooks (like running clippy) can take
advantage of the cache
* It also avoids installing the artifacts too soon (and making them
older than the source) and having cargo invalidate them
* Rather than clobbering the project's .cargo/config.toml file (if it
exists), the setup hook will update the base configuration used in
$CARGO_HOME/config.toml
* This potentially allows for projects who know what they are doing to
more easily replace their own sources, while falling back to our
configuration
* This will define CARGO_HOME to $PWD/.cargo-home to ensure that cargo
never tries to look for a missing HOME directory as it's default
location
* The hook is also added to `postPatchHooks` (instead of
`preConfigureHooks`) to ensure that it runs before all other
configuration-related hooks
* This should make it a bit easier to tell at a glance what inputs are
significant for the derivation without having to look at the entire
source (and corresponding hooks)
* The intention is to make it more clear that this flag controls copying
the target directory so that *other* derivations can use it, and DOES
NOT control whether we use an *existing* target directory from another
derivation
* If the source root contains a Cargo.lock file it will be used to
create a vendor directory
* Otherwise a (descriptive) error will be thrown describing how to
remediate
* The caller can, of course, manually specify their own `cargoVendorDir`
which will skip the default vendoring
* We can simplify the configuration by removing the
`doCopyTargetToSeparateOutput` parameter
* If a caller wants to copy target artifacts into any other output, it
is pretty trivial for them to add their own logic for it
