Skip to content
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

Cannot work offline #11074

Closed
ijackson opened this issue Sep 12, 2022 · 3 comments
Closed

Cannot work offline #11074

ijackson opened this issue Sep 12, 2022 · 3 comments
Labels
A-cli Area: Command-line interface, option parsing, etc. A-configuration Area: cargo config files and env vars C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`

Comments

@ijackson
Copy link
Contributor

Problem

I am about to board a ferry from Wales to Ireland. On the ferry and for much of the rest of my trip, I will have no useful internet access. I am developing a proc macro crate. That crate's tests use macrotest, which in turn runs cargo metadata and cargo expand.

These commands access the internet. I can run cargo --offline test but that doesn't help, because the inner cargo invocations run online.

As far as I can tell there is nothing sensible that the cargo expand crate, or the macrotest crate, could do about this. They could support a custom environment variable to add to their cargo runs, but that seems like a bad idea.

Proposed Solution

cargo should honour CARGOFLAGS. Then I could set CARGOFLAGS=--offline.

Additionally, cargo should honour --no-locked to override CARGOFLAGS=--offline --locked. That way, I could set CARGOFLAGS=--offline --locked and crates like macrotest that build little private projects could use --no-locked to indicate that they need to regenerate the lockfile. (Ideally they would somehow have their deps represented in the toplevel lockfile but I suspect that is too hard wth the current architecture of cargo.)

See also #9273 #8207 #11041.

In the meantime I am going to try putting a shell script wrapper called cargo on my PATH, which will force offline mode. I don't know how this will interact with rustup's cargo wrapper. Badly I suspect :-/.

Notes

No response

@ijackson ijackson added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Sep 12, 2022
@epage
Copy link
Contributor

epage commented Sep 12, 2022

As far as I can tell there is nothing sensible that the cargo expand crate, or the macrotest crate, could do about this. They could support a custom environment variable to add to their cargo runs, but that seems like a bad idea.

cargo expand supports --offline, so it does its part.

The interesting part is macrotest because the tests likely can't run with --offline in some scenarios (like fresh CI runs) which makes --offline a transient flag based on the environment and so doesn't belong in the macrotest crate or in the calls to the macrotest crate. As you call out, an environment variable is best. The main question is whether to be in macrotest or cargo (for now, not going to comment on that, just wanted to expand on the use case).

@epage epage added A-configuration Area: cargo config files and env vars A-cli Area: Command-line interface, option parsing, etc. labels Sep 12, 2022
@ehuss
Copy link
Contributor

ehuss commented Sep 12, 2022

Offline mode can be globally enabled via the net.offline config option. That can also be set with the CARGO_NET_OFFLINE=true environment variable.
Does that sufficiently handle your use case?

@ijackson
Copy link
Contributor Author

Offline mode can be globally enabled via the net.offline config option. That can also be set with the CARGO_NET_OFFLINE=true environment variable. Does that sufficiently handle your use case?

Oh! Yes. I had ruled out the config because the config file can't be overridden and arranging to use the right one is very awkward, but the "set config via environment variable" feature comes to the rescue here.

And all of this is documented, if one thinks to put together the right pieces. Sorry for the noise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cli Area: Command-line interface, option parsing, etc. A-configuration Area: cargo config files and env vars C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`
Projects
None yet
Development

No branches or pull requests

3 participants