Enable Cargo to work without any network access

[brson]

Build farms need to build Cargo projects without hitting the network. Assuming that distros rewrite their Cargo.tomls to convert dependencies to local paths, then as far as I know the other source of network access is just updating the index.

re https://internals.rust-lang.org/t/perfecting-rust-packaging-the-plan/2767

[aidanhs]

It'd also be nice if cargo didn't blow up if it fails to hit the network for downloading the index and instead tries to continue as far as possible.

[alexcrichton]

cc #1882

[brson]

For solving gecko's case, where they primarily don't want the build servers talking to the network, @alexcrichton favors a cargo package --deployment that creates a single tarball that contains the source code of the whole dag.

Even if we can sell that to gecko, I'm skeptical that Linux distros will like it - they want to use their package system to track Rust packages, and they don't want to duplicate the source of dependencies.

[cardoe]

So for Yocto, I would be comfortable with something similar to the Gecko use case. With Yocto the compilation of a package is broken up into several tasks (similar to Gentoo) and once the do_fetch task has ended there shouldn't be anymore network access. This is because Yocto supports users to build in no network access environments and to provide their own source cache which had previously been fetched. To best support this for Cargo built packages I call cargo fetch with a per-package CARGO_HOME set. This usually works but every now and then the sun/moon alignment upsets Cargo and it wants network access again during cargo build.

Hopefully that helps explain my use case and adds some support behind this item.

[vi]

+1
Maven (build tool for Java) does have offline mode, for example.

Failure to update registry (while there is some usable cached version) should suggest an option to switch offline mode on.

Editing dependency version in Cargo.toml just to discover that network is not available, then reverting it to old version number should bring offline-buildable setup back.

In general: Internet access shouldn't always be taken for granted.

[yoshuawuyts]

Having a node background, this behavior on cargo was unexpected:

• npm install installs dependencies
• npm install --cache-min Infinity installs dependencies from cache (slight hack)
• npm start runs the start script

These are separate steps because there are no guarantees as to where someone might be working from. I think Cargo should be reliable, regardless if people are hacking from the artic circle or enjoying the privilege of a fiber connection.

I think cargo build being build + install is a sane default for the connected parts of the world, but there should be a way to opt-out of this so everyone's use cases can be met.