Fixes linker errors while building build.rs where it tries to link libiconv but cannot find it.
Rust executable build for Darwin need libiconv, and indeed buildInputs already has this case handled.
So why is another change needed? Suppose we are cross compiling from Darwin (the build platform) to something else, and the package has a build.rs build script.
The build script is built for the build platform (Darwin) and is also a regular Rust executable, needing libiconv, but due to cross compilation (and strict deps) we need an extra nativeBuildInput.
writeShellApplication currently uses the unwrapped (passthru) attribute
which is simply defined as the ShellCheck Haskell package.
Unfortunately the unwrapped version contains everything and the kitchen
sink, while the bin output of the top-level shellcheck package contains
only the static shellcheck executable.
In other words, by using writeShellApplication, currently 3GB of
packages have to be unnecessarily fetched just to run the checkPhase.
$ nix path-info -Sh $(nix build --print-out-paths --no-link nixpkgs#shellcheck.unwrapped)
/nix/store/23x8702b9kqn0r8swah05ky7w5fnh6m2-ShellCheck-0.9.0 3.0G
$ nix path-info -Sh $(nix build --print-out-paths --no-link nixpkgs#shellcheck.bin)
/nix/store/594izb2jz3c57c7hgxfnb6irypnr4575-shellcheck-0.9.0-bin 45.3M
There is no benefit to using shellcheck.unwrapped in this case.
Therefore, replace shellcheck.unwrapped with lib.getExe shellcheck.
`cargoDeps` is already passed as `mkDerivation` arguments, and should
not be `passthru`ed again. This fixes the mismatch of `drv.cargoDeps`
and the actual dependency when the original derivation is overriden.
Previously, you had to provide the path to the deps.nix of the package inside
your Nixpkgs checkout as an argument manually. Now it just does that by default
when no argument is passed.
v1 lock files (generated by default by Cargo versions 1.40 and below)
use a single table, `metadata`, to store the checksums of packages.
The primary motivation for doing this now is that we're considering
vendoring all Cargo lock files in Nixpkgs, some packages still use it
(e.g. cargo-asm), and adding support for it doesn't increase the
complexity of the function. No matter the outcome of the vendoring
discussion, this is a nice thing to have because Cargo still supports v1
lock files.
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
Before this change, `nix develop` would often result in all the
shell's dependencies being copied to a remote builder, only for the
remote builder to run a trivial derivation build. This change makes
`nix develop` much faster on systems with remote builders configured.
Fixes "No such file or directory" error when running prefetch-npm-deps
in its default mode (print hashes, for update scripts etc),
in an environment that doesn't have a `nix` binary (for `nix hash`).
otherwise, eval fails when the experimental no-url-literals feature is activated
unquoted urls are discouraged after https://github.com/NixOS/rfcs/pull/45
Used in cases where you need to get the vendor of a target. Such as when
you need to perform dependency resolution outside of Cargo (eg in
Kolloch's crate2nix).
Currently cargo-setup-hook instructs the builder upon cargoSha256 or
cargoHash being out-of-date compared to the Cargo.lock file.
The instructions can be simplified a bit, because nowadays it is fine to
keep a hash empty, instead of filling it with
`0000000000000000000000000000000000000000000000000000`.
Nix nowadays outputs SRI hashes, which should usually be placed in
`cargoHash` instead of `cargoSha256`, but the instructions are still
only referring to `cargoSha256`.
Lastly, the output of Nix doesn't include `got: sha256: ` anymore, as it
now outputs `got: sha256-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=`.
It would be nice to make it clear that the trailing `=` is important as
well, so the full example SRI hash is mentioned.
