-
Notifications
You must be signed in to change notification settings - Fork 99
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
RTS build: don't vendor Rust deps #2829
Conversation
Vendoring dependencies is causing a lot of problems in #2761 and other PRs, because `cargo vendor` currently has a bug and cannot vendor standard dependencies (deps of alloc and std, see rust-lang/wg-cargo-std-aware#23). For a long time I thought vendoring is a necessity and tried to work around this issue by vendoring dependencies manually, or using https://github.com/nix-community/naersk. However, it turns out vendoring is not necessary, and we can download dependencies in build step just fine. I also don't see any advantages of vendoring the dependencies. So in this PR we remove vendoring. Unblocks #2761.
Sigh... This works fine locally but on CI fails because I think it can't download stuff in build step? I don't understand why it can download stuff in preBuild step (for vendoring) but not in build step.. |
Weird, CI passed on macos, but not on Ubuntu. Maybe a problem with Ubuntu CI configuration? (I've restarted CI) |
Downloading stuff in nix builds is of course a no-go; how else would you achieve hermeticity - the content of the URL could change, making the build nonreproducable. It may appear to work in some system configurations that don't sandbox the build (e.g. on Darwin CI, it seems), but it (rightfully) will not work on properly sandboxed builds. There is a reason naersk etc exists and does this step where it downloads the dependencies first to a “fixed output derivation”, where the content (hash) is declared ahead of time, and which therefore are allowed to do unsafe things. |
We already download stuff from crates.io today. It just happens in Why is it a problem to download in |
I would be very surprised if that makes a difference, these steps are just different parts of essentially one big shell script. . Are you sure it's not the difference between a normal build and a fixed-output build (like the normal vendoring build step)? |
Ah, you're right, I'm a bit confused about why we are able to download packages for vendoring, but not for building. The
is used in
So downloading the packages should happen in |
Both are builds (i.e. a derivation, producing a store path when built). But the vendoring build has, as part of it's build instructions, the hash of the result. This is the cargo hash we have to manually update. The build would fail if that doesn't match after running the build steps, and therefore the build is reproducible by construction. And so these fixed-output derivations are allowed to access the internet, in contrast to the normal derivations. |
OK, this makes sense. I wonder if naersk uses |
Vendoring dependencies is causing a lot of problems in #2761 and other
PRs, because
cargo vendor
currently has a bug and cannot vendorstandard dependencies (deps of alloc and std, see
rust-lang/wg-cargo-std-aware#23).
For a long time I thought vendoring is a necessity and tried to work
around this issue by vendoring dependencies manually, or using
https://github.com/nix-community/naersk.
However, it turns out vendoring is not necessary, and we can download
dependencies in build step just fine. I also don't see any advantages of
vendoring the dependencies. So in this PR we remove vendoring.
Unblocks #2761.