Cargo is "Updating registry '...'" offline, even with a Cargo.lock


#1

I am currently attempting to work on a project from an airport. The wifi here isn’t working though so my PC is offline. Unfortunately, when trying to build my application, I am met with an attempt to update registry, followed by a notification that the update failed because I am offline. I thought that a valid Cargo.lock file would allow bypassing the registry update. Is that correct or is there any reason that this would fail?

I can follow up with more details when I land and especially when I have proper wifi.

Note: I am sending this message from a phone.


#2

Here is some more info which may be relevant:

My project is divided into a few modules. At the top level a .cargo/config enumerates the modules to make local development easier (cross module changes are possible without republishing). I’m thinking that this may be part of the issue.

If I rebuild one of the leaf modules with no dependencies in the .cargo/config, the build works. Furthermore, it looks like the failing modules are those which depend on modules that have been changed locally. Is this the correct behavior?


#3

I think I’d use path = "" lines in each dependency instead of using overrides, at least if the projects are for example all in the same repository or closely interlinked. Packages can use both path = and version = in their deps and can be published as long as the dependencies exist on crates.io too.

However, I’m not sure if that it removes the need to go to the registry(?) It looks like it tries to query the registry here, even if I add a new path = using dependency.


#4

I just tried switching the dependencies to path dependencies. No luck. Some modules still attempt to hit registry.


#5

What cargo --version are you running?

This cargo issue sounds relevant, or maybe this one and the issues linked to it. Or you might have found a new issue!


#6

After spending more time with this I got my project to successfully compile offline. By replacing my version dependencies with path dependencies and then compiling online, I am able to compile offline. Indeed, the previously mentioned link provides this solution but it comes with its own problems:

  1. There is an initial need to compile online before any compilation offline can be done. This happens even if the only things that have changed are path dependencies.
  2. I cannot individually publish modules like this because they have path dependencies in them. This is the issue I was trying to resolve by using ‘.cargo/config’. The top level of my project is a typescript/electron program which loads an exe (backend) and dlls (plugins) and provides a GUI for them. The two rust modules (the .exe and .dll) share another module in the project and ideally would be published separately. If I wanted to work offline, it looks like I would have to maintain two cargo.toml files for each module, one for developing, and one for publishing.

Combining 1 and 2, I would have to know I was going to be offline before hand so that I could switch to the .toml files with path dependencies and then do a cargo fetch while still online.

Note: to be a little more clear about my setup, this is what it looks like:

|- .cargo/config
|- frontend (typescript)
|- backend (rust, .exe, depends on environment)
|- plugins (rust, .dll, depends on environment, there may be multiple plugins)
|- environment (rust, .rlib)

#7

You can publish modules that use path dependencies, their dependencies just must be available on crates.io as well. I don’t know if there’s a special case where this is not true?


#8

I think mixed dependencies is a case where it isn’t true. In other words, a module with both path and version dependencies.


#9

For example, arrayvec can be published, but locally it uses path to nodrop. https://github.com/bluss/arrayvec/blob/d86f06b068f65733fa8b7f4602aad0499ffe38ad/Cargo.toml#L17-L20


#10

Ohhhhhhhh, very interesting. I didn’t realize that dependencies could be specified like that. Thank you very much. I will see if that fixes my problem.