* 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.
* 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
* This allows for fewer assumptions about the project structure
* The old behavior can easily be brought back by setting `cargoExtraArgs
= "--workspace";` in any derivation
* 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
* Rather than recursively look up all paths in a given project and then
filtering for cargo-specific files, we now use our own customized
traversal method to only capture the results we want.
