Crates from git repos are vendored in a flattened directory where each crate shows up at the root of the vendor directory. Since the vendoring step effectively breaks workspace structures, any crates which use workspace inheritance (e.g. package.version.workspace = true will fail to resolve.
To work around this we inspect the crate's workspace manifest (if it exists) and attempt to manually merge the values while copying the contents to the vendor directory.
Using `cp --no-preserve mode` ends up losing the executable bit of
previously compiled build scripts. Instead we should ignore the file
ownership, and subsequently make the files writable (since the store is
read only)
* mkDummySrc: also include `no_std` attrs for target_os = uefi
* buildDepsOnly: only check with `--all-targets` if doCheck enabled
* mkDummySrc: allow customizing dummy Rust file contents
* Instead of injecting our own dummy `build.rs` file, we will patch the
`Cargo.toml` files to specify a build script in the Nix store
* This allow cargo to notice the difference (i.e. changed build script
path) where it could not before (due to nix enforcing that all sources
always have the same timestamp)
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 trying to use crane with a non local src (eg, not `./.`) we get the error
```
$ nix flake show
<...>
error: access to absolute path '/Cargo.toml' is forbidden in pure eval mode (use '--impure' to override)
(use '--show-trace' to show detailed location information)
```
To fix this, we quote the relative paths so to properly append them to the base path.
https://nixos.wiki/wiki/Nix_Expression_Language#Coercing_a_relative_path_with_interpolated_variables_to_an_absolute_path_.28for_imports.29
## Reproduction flake
```
{
description = "Build a cargo project without extra checks";
inputs = {
nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";
crane = {
url = "github:ipetkov/crane";
inputs.nixpkgs.follows = "nixpkgs";
};
external-crate-source = {
url = "github:ray-kast/empress";
flake = false;
};
flake-utils.url = "github:numtide/flake-utils";
};
outputs = { self, nixpkgs, crane, flake-utils, external-crate-source, ... }:
flake-utils.lib.eachDefaultSystem (system:
let
pkgs = nixpkgs.legacyPackages.${system};
test-crate = crane.lib.${system}.buildPackage {
src = external-crate-source.outPath;
};
in
{
packages.default = test-crate;
});
}
```
* 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
