You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had CARGO_UNSTABLE_SPARSE_REGISTRY=true in my dev environment, and running cargo run -- build crate rustls 0.20.0 failed with a lot of errors like:
[INFO] [stderr] warning: spurious network error (1 tries remaining): [6] Couldn't resolve host name (Could not resolve host: crates.io)
This is because we fetch dependencies outside the rustwide container, and make them available (via filesystem) inside the container. In my setup, CARGO_UNSTABLE_SPARSE_REGISTRY=true was being observed outside the container, but of course the container does not inherit the environment variable. So cargo inside the container was not seeing the prefetched files and was trying to fetch them.
The big fix here would be to do the fetching inside its own container, which does have network access (unlike the building container).
A couple of smaller fixes we could make:
Pass --offline to cargo inside the container so it fails less opaquely if it would need to access the network.
Filter all CARGO_* vars from the env before calling cargo.
The text was updated successfully, but these errors were encountered:
Thinking about it a little more it seems like a cargo bug that it can't use a lockfile and cache from -Zsparse-registry in a build without it, rust-lang/cargo#10722 is sort of related. Left a comment on rust-lang/cargo#9069.
I had CARGO_UNSTABLE_SPARSE_REGISTRY=true in my dev environment, and running
cargo run -- build crate rustls 0.20.0
failed with a lot of errors like:This is because we fetch dependencies outside the rustwide container, and make them available (via filesystem) inside the container. In my setup, CARGO_UNSTABLE_SPARSE_REGISTRY=true was being observed outside the container, but of course the container does not inherit the environment variable. So cargo inside the container was not seeing the prefetched files and was trying to fetch them.
The big fix here would be to do the fetching inside its own container, which does have network access (unlike the building container).
A couple of smaller fixes we could make:
--offline
to cargo inside the container so it fails less opaquely if it would need to access the network.The text was updated successfully, but these errors were encountered: