Outdated lock file when workspace level dependencies

[YuhanunCitgez]

Issues with outdated lock files occur if you have a workspace level dependency that's inherited by child projects.

Error:

 ✘  ~/sandbox/nix   master ±  cargo generate-lockfile && nix run -L github:cargo2nix/cargo2nix
    Updating crates.io index
Version 0.11.0 matches the requirement >=0.11 [0.11.0]
warning: do you want to overwrite 'Cargo.nix'? yes/no: yes
error: the lock file /home/ycitgez/sandbox/nix/Cargo.lock needs to be updated but --locked was passed to prevent this
If you want to try to generate the lock file without accessing the network, remove the --locked flag and use --offline instead.

Cargo.toml:

[workspace]
members = [
    "some-bin",
    "some-lib"
]

[workspace.dependencies]
time = { version = "0.3.22", features = ["macros"] }

some-bin/Cargo.toml

[package]
name = "some-bin"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

some_lib = { path = "../some-lib", package = "some-lib" }
time = { workspace = true }

some-lib/Cargo.toml

[package]
name = "some-lib"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

[psionic-k]

Okay. Looks like a bug. I'll see if I can work in cargo's own way of deciding to perform the update. IIRC there's some high level code that just does it before operations that rely on the lock.

[psionic-k]

I added in some rudimentary support for updating the lock file. It's easy to trip over a stale lock file. The behavior is not yet ideal.

The --locked option now exists to prevent this behavior if you want to use a "stale" lock file, such as one you hand edited to get around a bug.

Usually modifying the Cargo.nix by hand is easier, but of course both of these are not scalable workarounds.

What's no my mind is that each cargo2nix build has a specific cargo version it's tied to. If it was a cargo plugin that used cargo from your shell via metadata (possible in recent versions), we can get around this limit, and it makes more sense to go that way anyway.

If I'm not going the plugin route, I need to make cargo2nix do a bit more nuanced handling to detect but inquire about stale lock files.

I'm thinking I will go the plugin route immediately after fixing up the feature handling to emit platform dependencies correctly

[YuhanunCitgez]

Awesome! Let me know if there's anything I can do to help.

It's going to be either cargo2nix or nocargo for the company I work for so getting either one to work would be nice. (Albeit... bazel is probably better for what we're trying to do but yea).

Let me know if I can be of any assistance.

[psionic-k]

For running a company, my wish list would be:

• k8's containers built with musl
• wasm for web clients (and frequently distributed by web servers in containers)
• API specs and client generation to use Rust business objects and API definitions across the organization

More linking options for embedded is another large ask. All of these are high value for people to use Nix in production. Do any of them align with your company's needs?

[YuhanunCitgez]

For running a company, my wish list would be:

• k8's containers built with musl
• wasm for web clients (and frequently distributed by web servers in containers)
• API specs and client generation to use Rust business objects and API definitions across the organization

More linking options for embedded is another large ask. All of these are high value for people to use Nix in production. Do any of them align with your company's needs?

We don't build web clients in Rust. Would be nice to be able to generate API specs from an Axum API or something but im sure that can just be a cargo build.rs :P

The MUSL builds would be amazing, plug and play nix build -L .#containers which can be pushed to an ECR registry. I really do want to help there actually, I'm intermediate level at Nix so.... (noticed this one very late, happy new year btw :P )

[psionic-k]

I've done MUSL container builds before. The examples in cross compiling show part of the way. The correct crossSystem will IIRC obtain a MUSL build.

There's some friction around obtaining both non-cross and cross builds in the same flake. It's easy, just slightly senseless in terms of extra boilerplate. This boilerplate is not required for any architectural reason, just legacy and lack of development.

[YuhanunCitgez]

I've done MUSL container builds before. The examples in cross compiling show part of the way. The correct crossSystem will IIRC obtain a MUSL build.

There's some friction around obtaining both non-cross and cross builds in the same flake. It's easy, just slightly senseless in terms of extra boilerplate. This boilerplate is not required for any architectural reason, just legacy and lack of development.

Yeah I'm sure it's possible, might be nice to have it be part of the cargo2nix featureset, I might be able to start adding it, if you let me know where to look :P

[psionic-k]

It's there. I did it with cargo2nix before. It's just a little bit ugly because you have to declare nixpkgs twice. It should instead be a partial that is evaluated for each target, giving packages..name or something like that.