How to deal with mismatched lockfile?

[eureka-cpu]

I realized at some point I must have removed --locked from my derivations built with crane to just get past the error, but now that I want to add --locked back in, it would seem I can't get past the error about lockfiles not matching because I passed --locked.

error: Cannot build '/nix/store/jlc1cccgv2q2smam31gkfihybz2qacw2-reacloudctl-0.1.0.drv'.
       Reason: builder failed with exit code 101.
       Output paths:
         /nix/store/vybypsc08bzwakg1zlci16pp7n79863a-reacloudctl-0.1.0
       Last 16 log lines:
       > Running phase: unpackPhase
       > unpacking source archive /nix/store/lyw12xrd54jv7l3fpg7fdns6zg0jzxv0-source
       > source root is source
       > Running phase: patchPhase
       > Executing configureCargoCommonVars
       > decompressing cargo artifacts from /nix/store/plk0sh0417x8a3076c94x9ddvpfzww39-cloud-reaper-deps-0.1.0/target.tar.zst to target
       > Running phase: updateAutotoolsGnuConfigScriptsPhase
       > Running phase: configurePhase
       > will append /build/source/.cargo-home/config.toml with contents of /nix/store/jhw9al9whqn22lbxddr38jwcw6dwdscq-vendor-cargo-deps/config.toml
       > default configurePhase, nothing to do
       > Running phase: buildPhase
       > +++ command cargo --version
       > cargo 1.95.0 (f2d3ce0bd 2026-03-21)
       > +++ command cargo build --release --message-format json-render-diagnostics --bin reacloudctl --locked
       > error: cannot update the lock file /build/source/Cargo.lock because --locked was passed to prevent this
       > help: to generate the lock file without accessing the network, remove the --locked flag and use --offline instead.
       For full logs, run:
         nix log /nix/store/jlc1cccgv2q2smam31gkfihybz2qacw2-reacloudctl-0.1.0.drv
error: Cannot build '/nix/store/m8mlyrmvli086p5y8wjc3bp70n9zr59g-reacloud.drv'.
       Reason: 1 dependency failed.
       Output paths:
         /nix/store/3qjlyk9g7g607a4frhsxx26z0mg73x58-reacloud
error: Build failed due to failed dependency

My expression for that crate is this, though I get the error for all crates. Removing --locked makes it build just fine.

  reacloudctl = buildPackage (individualCrateArgs // {
    pname = "reacloudctl";
    src = toManifestSource {
      crate = workspace.root + "/src/reacloudctl";
      deps = [
        "/src/libreacloud"
        "/src/libreacloudd"
        "/src/reacloud_client"
        "/src/stitches_client"
      ];
    };
    cargoExtraArgs = "--bin reacloudctl --locked";
  });

[dpc]

I'm probably missing something, but the up to date Cargo.lock must be checked in.

[dpc]

Yes. Probably it. Visibility of each crate would change the workspace composition, and resulting Cargo.lock, I guess.

You generally want to build the dependencies for the whole workspace once, and then maybe from there build particular crates.

But even then, I would generally recommend building everything (whole workspace), and if you want to have derivations with single binaries, build these by just taking particular binary out of the resulting whole-workspace build.

Trying to filter out workspace members is trying to save something that wouldn't be built anyway. And trying to build things individually to avoid rebuilding different workspace members is getting into rust2nix, etc. approaches, which crane does not support, and IMO have more overall overhead than benefit.

[ipetkov]

If slicing up the workspace to ignore specific crates results in different feature unification (and by extension, changes what "optional" dependencies are/aren't included) then yes this can result in a different lockfile

[eureka-cpu]

Ah I see. For some reason I figured this wouldn't matter because of cargo hakari being the unifying crate, but perhaps I misunderstood.

[ipetkov]

Keep in mind that your own workspace dependencies also show up as entries in the lockfile. If you explicitly enumerate workspace members (as opposed to enumerating "entry points" as cargo already implicitly promotes all path deps to workspace members) its possible that may also be causing cargo to consider the lockfile needing to be updated

[eureka-cpu]

Yeah, perhaps this isn't the most logical pattern to keep anyway. I'll take @dpc's advice and remove the extra crate level path restriction.