`fixupPhase` move `$out/man` to `$out/share/man`. So the information of their location in the dune-project file is outdated which breaks dependencies on packages ( `(package foo)`).
(and gitiles)
This allows fetching a patch from servers that return them
base64-encoded, like this:
fetchpatch {
name = "gcc.patch";
url = "f37ae3b1a8^!?format=TEXT";
decode = "base64 -d";
sha256 = "11j1bqz2p8xrfzgfrylgdvmqs45489c4ckl7l0ra1dpfgbqy94a8";
}
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).
