-
-
Notifications
You must be signed in to change notification settings - Fork 13.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[replace] doesn't replace in rustBuildPackage #22177
Comments
I think this is not a bug in Are you sure you are specifying the version inside the You can check if the version is correct with If you specified the version correctly, you can try instead to put the output of Alternatively, and this may require a lot more work, you can try to either switch to the unstable branch of nixpkgs/NixOS, or to backport all the Rust-related changes in the unstable branch to your own local git checkout of the stable branch. I have done the latter some time ago and I was able to successfully build the package as you specified in your "steps to reproduce" section (although, I had to add a |
It occurred to me that you could check a couple of additional issues:
|
Yes, because
I'm working on a modified local checkout of nixpkgs, and I tried this both with my own rustup nightly fetcher, and the one in NixOS unstable. My problem is, my project requires Rust nightly, and ring 0.6.2 stopped building on nightly this week (I could build it with rustup from January 22nd). |
I am having the same issue trying to make a package for "spotifyd" |
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly:
|
replace now crashes the build with a bad symlink error: builder for '/nix/store/g5k2iq1gn2bw7c967dx2g6hjj2ahdil4-cargo-vendor-dir.drv' failed with exit code 1;
last 1 log lines:
> ln: failed to create symbolic link '/nix/store/dshpabbp5irzg2001fg5kj1spngb0260-cargo-vendor-dir/rnix-0.10.1/y4xbapipnj4vpp7b24srw43scnl5k62m-rnix-0.10.1': Permission denied
For full logs, run 'nix log /nix/store/g5k2iq1gn2bw7c967dx2g6hjj2ahdil4-cargo-vendor-dir.drv'. Full log is just the same line |
While a theoretically awesome tool, Nix has demonstrated a pair of extremely deleterious shortcomings that appear to be not considered important by the Nix Community. Specifically: - Nix relies on the manual entry of input hashes for Cargo dependencies. This is extraordinarily cumbersome, and causes build failures on any dependency change. There was a suggestion to get this information automatically, but this has been stalled since 2019 (over 3 years, at the time of this commit): NixOS/nixpkgs#63653 - Nix appears to be unable to handle multiple versions of Rust packages gracefully. The result is unexpected and uncommunicative failures, such as a failure to generate a symlink. This class of failure was first reported in 2017 (over 5 years ago, at the time of this commit): NixOS/nixpkgs#22177 As a result, I do not believe that Nix can offer us a reliable platform for CI of Hubris at this time. As observed on #46, attempting to appease Nix can result in significant crate changes to facilitate single revision jumps - consuming days of effort to validate a change that is essentially operational.
While a theoretically awesome tool, Nix has demonstrated a pair of extremely deleterious shortcomings that appear to be not considered important by the Nix Community. Specifically: - Nix relies on the manual entry of input hashes for Cargo dependencies. This is extraordinarily cumbersome, and causes build failures on any dependency change. There was a suggestion to get this information automatically, but this has been stalled since 2019 (over 3 years, at the time of this commit): NixOS/nixpkgs#63653 - Nix appears to be unable to handle multiple versions of Rust packages gracefully. The result is unexpected and uncommunicative failures, such as a failure to generate a symlink. This class of failure was first reported in 2017 (over 5 years ago, at the time of this commit): NixOS/nixpkgs#22177 As a result, I do not believe that Nix can offer us a reliable platform for CI of Hubris at this time. As observed on #46, attempting to appease Nix can result in significant crate changes to facilitate single revision jumps - consuming days of effort to validate a change that is essentially operational.
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/rust-with-git-deps-symbolic-link-error-to-cargo-vendor-dep/28841/1 |
Issue description
The
[replace]
section ofCargo.toml
is not handled bybuildRustPackage
, which issues the following warning (in my case, when replacing packagering:0.6.2
with a local version):That section can be used to override a package with some locally fixed package.
This is not a big problem until one tries to quickly fix a bug in a dependency and
nixops
it into production.Steps to reproduce
Create a crate with the following
src/main.rs
:Clone
http://github.com/briansmith/ring
at the root of the crate.And the following lines in
Cargo.toml
:Now package it with
rustBuildPackage
. The replacement is ignored.Technical details
System: (NixOS:
nixos-version
, Ubuntu/Fedora:lsb_release -a
, ...)16.09.1515.89c567c (Flounder)
Nix version: (run
nix-env --version
)nix-env (Nix) 1.11.6
Nixpkgs version: (run
nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion
)17.03pre-git
The text was updated successfully, but these errors were encountered: