mirror of
https://github.com/NixOS/nixpkgs.git
synced 2025-06-12 04:35:41 +03:00
rustPlatform.fetchCargo: handle custom Cargo.lock patchfiles with validation
Previously, we would asssert that the lockfiles are consistent during the unpackPhase, but if the pkg has a patch for the lockfile itself then we must wait until the patchPhase is complete to check. This also removes an implicity dependency on the src attribute coming from `fetchzip` / `fetchFromGitHub`, which happens to name the source directory "source". Now we glob for it, so different fetchers will work consistently.
This commit is contained in:
parent
71d5e1595c
commit
ad30a30488
6 changed files with 1092 additions and 23 deletions
|
@ -53,10 +53,12 @@ all crate sources of this package. Currently it is obtained by inserting a
|
|||
fake checksum into the expression and building the package once. The correct
|
||||
checksum can be then take from the failed build.
|
||||
|
||||
When the `Cargo.lock`, provided by upstream, is not in sync with the
|
||||
`Cargo.toml`, it is possible to use `cargoPatches` to update it. All patches
|
||||
added in `cargoPatches` will also be prepended to the patches in `patches` at
|
||||
build-time.
|
||||
Per the instructions in the [Cargo Book](https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html)
|
||||
best practices guide, Rust applications should always commit the `Cargo.lock`
|
||||
file in git to ensure a reproducible build. However, a few packages do not, and
|
||||
Nix depends on this file, so if it missing you can use `cargoPatches` to apply
|
||||
it in the `patchPhase`. Consider sending a PR upstream with a note to the
|
||||
maintainer describing why it's important to include in the application.
|
||||
|
||||
Unless `legacyCargoFetcher` is set to `true`, the fetcher will also verify that
|
||||
the `Cargo.lock` file is in sync with the `src` attribute, and will compress the
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue