Reputation: 3271
How do I disable cargo update
or cargo build
from attempting to access github.com; but still download the appropriate package from crates.io
I have a single dependency in my cargo.toml
[dependencies]
chrono = "0.2.14"
Running cargo build
E:\>cargo build
Updating registry `https://github.com/rust-lang/crates.io-index`
Unable to update registry https://github.com/rust-lang/crates.io-index
We are blocked from github.com at work but not crates.io. Is there an option where cargo can still download the packages it needs without needing to update it's registry?
Upvotes: 14
Views: 8826
Reputation: 3631
Since the registry.index config value is no longer supported, I could replace official crates.io registry use adding this .cargo/config file in my project (or under $CARGO_HOME%\.cargo) :
[source]
[source.mirror]
registry = "http://localhost:8185/auser/crates.io-index.git"
[source.crates-io]
replace-with = "mirror"
Also works using a file based git registry clone:
registry = "file://c:/github/crates.io-index.git"
downloaded either using git clone --bare or --mirror
cargo build now print
Updating 'c:\github\crates.io-index.git' index
instead of Updating crates.io index
Upvotes: 0
Reputation: 1260
Sadly, cargo support --offline
and config with net.offline
only.
This flag add in this PR.
Upvotes: 0
Reputation: 58975
If you look at the documentation for configuring Cargo, you'll note there is an index
key in the [registry]
section. This can be any path to a Git repository.
As such, you can make a local clone of the crates.io index. I verified this by cloning it like so:
git clone --bare https://github.com/rust-lang/crates.io-index.git
then editing my Cargo configuration (specifically, I changed ~/.cargo/config
, but this should work anywhere the documentation describes) to contain:
[registry]
index = "file:///F:/Data/Repositories/crates.io-index.git"
A few things to note:
This does not mirror the actual contents of the packages. Those come from a different host. I do not know how to mirror those, however: Cargo is much better about caching those locally. It should be enough to cargo fetch
packages, then copy the cached *.crate
files in $HOME/.cargo/registry/cache/*
.
This causes the package identifiers in your Cargo.lock
file to change. This isn't a problem for developing libraries, but it does become a problem for binaries. Standard practice is to check your Cargo.lock
into source control for binaries so that everyone downstream builds with the exact same package versions. However, the modified index means no one else will be able to build the package with that lock file in place.
I've worked around this by placing another config override within binary packages that resets the index to the "official" one, but that may not even be possible in your situation. In that case, you may need to either exclude Cargo.lock
from source control, or just have a "doesn't use the official index" branch.
Upvotes: 16