update nixpkgs

[Steven0351]

The rust compiler in the current pinned version of nixpkgs is not compatible with the current state of the project. I opened a similar PR for crisidev/bacon-ls#87. Here is the full error for reference:

error: Cannot build '/nix/store/ny3zrmh19ks5sxr3ygy49p14sx1qfdj9-bacon-deps-3.20.1.drv'.
       Reason: builder failed with exit code 101.
       Output paths:
         /nix/store/2iac7aj8ch5r832jmdzq16s6i48247xv-bacon-deps-3.20.1
       Last 25 log lines:
       > [naersk] CARGO_BUILD_RUSTFLAGS:
       > [naersk] CARGO_BUILD_RUSTFLAGS (updated):  --remap-path-prefix /nix/store/7xxw4q0vjh0gslq3wykk89gissgcl9im-crates-io-dependencies=/sources --remap-path-prefix /nix/store/ddf1s2ajwli6qbxwq1bnad1sxdzmb7f7-git-dependencies=/sources
       > Running phase: buildPhase
       > cargo build $cargo_release -j "$NIX_BUILD_CORES" --message-format=$cargo_message_format
       > error: failed to get `anyhow` as a dependency of package `bacon v3.20.1 (/nix/var/nix/builds/nix-38127-2199272316/dummy-src)`
       >
       > Caused by:
       >   failed to load source for dependency `anyhow`
       >
       > Caused by:
       >   Unable to update registry `crates-io`
       >
       > Caused by:
       >   failed to update replaced source registry `crates-io`
       >
       > Caused by:
       >   failed to parse manifest at `/nix/store/7xxw4q0vjh0gslq3wykk89gissgcl9im-crates-io-dependencies/coreaudio-sys-0.2.17-ceec7a6067e62d6f931a2baf6f3a751f4a892595bcec1461a3c94ef9949864b6/Cargo.toml`
       >
       > Caused by:
       >   feature `edition2024` is required
       >
       >   The package requires the Cargo feature called `edition2024`, but that feature is not stabilized in this version of Cargo (1.83.0 (5ffbef321 2024-10-29)).
       >   Consider trying a more recent nightly release.
       >   See https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#edition-2024 for more information about the status of this feature.
       > [naersk] cargo returned with exit code 101, exiting
       For full logs, run:
         nix log /nix/store/ny3zrmh19ks5sxr3ygy49p14sx1qfdj9-bacon-deps-3.20.1.drv
error: Cannot build '/nix/store/2vkgn2d8vwxfrlh0rfz1lk4ay7rspfc4-bacon-3.20.1.drv'.
       Reason: 1 dependency failed.
       Output paths:
         /nix/store/4ilc52qgg1xxn8ivp5z9sn3j18br0hfl-bacon-3.20.1

[Steven0351]

Not sure if this project has any kind of CI anywhere, but this could be caught by just running nix build . as part of a pipeline. Another solution can be to use https://github.com/oxalica/rust-overlay which is compatible with rustup's rust-toolchain.toml

[Canop]

I have 0 nix expertise. Can you please give me the references of the package versions used to help me review the PR and get some insight on the problem ?

[alerque]

I believe this is resolved by #409. I just did a test run using the Nix Flake in place and it seems to work fine with that PR merged. I think this was essentially the same problem as #407 where the speced deps were incompatible with the speced Rust toolchain. Obviously the pinned Rust compiler in the Flake could be bumped too, but I don't think any changes at all are necessary now that the MSRV is respected.

[Steven0351]

I have 0 nix expertise. Can you please give me the references of the package versions used to help me review the PR and get some insight on the problem ?

It looks like the previous version of rust tools included in rev 4bc9c909d9ac828a039f288cf872d16d38185db8 of nixpkgs was 1.83. The version of rust tools included in this update is 1.91.

However, to @alerque's point, this is now compiling just fine with nix build on the latest main.

[Canop]

Can we close this ?

Another issue could be open requesting that the build chain incorporates a check for nix build compatibility

[alerque]

Yes I think this can be closed. There might be a point in doing a lock file refresh later (e.g. just prior to a release) and checking that it builds prior to release tagging (a CI job would be great for that) but I don't see any point in bumping it right now because it will be essentially a NOOP on the end user binary generated but force everybody to fetch and build a whole bunch of toolchain things in between that they probably already have cached at current versions. It's just churn that nobody needs when nothing is actually affected in the end.