[v2] rust: Write to .cargo/config.toml instead of .cargo/config

[mmlb]

Description of changes

Changes the rust infra to write cargo config to .cargo/config.toml insted of .cargo/config since the latter is deprecated (since 1.38?) and is now warning on stderr.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

---

Changes since v1:

• Avoid changing cargoHash for FOD
• Build/fixup more packages

[mmlb]

This time I've verified that no cargoHash changes to FOD happens (note, this was from when I based on master, waiting on building-most-of-the-world now that I rebased on staging):

[18:14:12]-[~/c/g/n/nixpkgs]-[manny@c3mv18nix]
git status
On branch rust-write-config.toml-not-config
nothing to commit, working tree clean
[18:14:18]-[~/c/g/n/nixpkgs]-[manny@c3mv18nix]
git rev-parse HEAD
c935d4b1ba9800c06629b7d3c39f156d52c32c9d
[18:14:20]-[~/c/g/n/nixpkgs]-[manny@c3mv18nix]
git grep cargoHash pkgs/by-name/co/commitmsgfmt/package.nix
pkgs/by-name/co/commitmsgfmt/package.nix:  cargoHash = "sha256-jTRB9ogFQGVC4C9xpGxsJYV3cnWydAJLMcjhzUPULTE=";
[18:14:24]-[~/c/g/n/nixpkgs]-[manny@c3mv18nix]
sed -i '/cargoHash/ s|".*"|""|' pkgs/by-name/co/commitmsgfmt/package.nix
[18:14:53]-[~/c/g/n/nixpkgs]-[manny@c3mv18nix]
nix-build -A commitmsgfmt 2>&1 | tail -n 5
calling 'postFixup' function hook '_multioutPropagateDev'
error: hash mismatch in fixed-output derivation '/nix/store/k0sfjvbjx1binzpm5b36n02a030rzdy9-commitmsgfmt-1.6.0-vendor.tar.gz.drv':
         specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
            got:    sha256-jTRB9ogFQGVC4C9xpGxsJYV3cnWydAJLMcjhzUPULTE=
error: 1 dependencies of derivation '/nix/store/x925hf14jii50vzlniamja7yb2726dzd-commitmsgfmt-1.6.0.drv' failed to build
[--:--:--]-[~/c/g/n/nixpkgs]-[manny@c3mv18nix]

[mmlb]

This should be the proper fix to close #320294

[mmlb]

And same steps to verify no change to cargoHash now off of staging:

[20:23:02]-[~/c/g/n/nixpkgs]-[manny@c3mv18nix]
git status
On branch rust-write-config.toml-not-config
nothing to commit, working tree clean
[20:23:04]-[~/c/g/n/nixpkgs]-[manny@c3mv18nix]
git rev-parse HEAD
4d384b1cf0afb65a5b1c3e7ecb4754a292662bcb
[20:23:08]-[~/c/g/n/nixpkgs]-[manny@c3mv18nix]
git grep cargoHash pkgs/by-name/co/commitmsgfmt/package.nix
pkgs/by-name/co/commitmsgfmt/package.nix:  cargoHash = "sha256-jTRB9ogFQGVC4C9xpGxsJYV3cnWydAJLMcjhzUPULTE=";
[20:23:10]-[~/c/g/n/nixpkgs]-[manny@c3mv18nix]
sed -i '/cargoHash/ s|".*"|""|' pkgs/by-name/co/commitmsgfmt/package.nix
[20:23:14]-[~/c/g/n/nixpkgs]-[manny@c3mv18nix]
nix-build -A commitmsgfmt 2>&1 | tail -n 5
calling 'postFixup' function hook '_multioutPropagateDev'
error: hash mismatch in fixed-output derivation '/nix/store/y58pyqfr0ad4pwwkwn4mlnr1bvn7xzsf-commitmsgfmt-1.6.0-vendor.tar.gz.drv':
         specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
            got:    sha256-jTRB9ogFQGVC4C9xpGxsJYV3cnWydAJLMcjhzUPULTE=
error: 1 dependencies of derivation '/nix/store/vxhj2yakd59ciqip8my6zz39pahj83vd-commitmsgfmt-1.6.0.drv' failed to build

[winterqt]

I'm not sure if this will just time out or not, but let's see.

@ofborg build fd

[mmlb]

@winterqt looks like it succeeded (FOD being FOD, its not much a signal though... right?). Any other worries? Also ping ping @zowoq @figsoda @Mic92 @mbalatsko

[emilazy]

LGTM in principle.

[emilazy]

Non‐blocking nit: If we’re changing this hook anyway we could get rid of this unnecessary ;.

[mmlb]

can do

[mmlb]

updated/removed

[emilazy]

This is an improvement over the status quo either way, but: this doesn’t adjust the fetchCargoTarball behaviour, which is good, but that means it’s still writing to the deprecated location. Doesn’t that mean we’ll still get warnings if we don’t mv or ln it in the build hooks? Do we not use those files at all somehow?

[VuiMuich]

Would we want to symlink ln -s .cargo/config.toml .cargo/config for compatibility to cargo 1.38 and earlier proactively, or should we wait for some occurrence?

Closes #334857

[emilazy]

From discussion on Matrix I think we decided that we don’t need to support 5+ year old compilers in Nixpkgs.

[VuiMuich]

From discussion on Matrix I think we decided that we don’t need to support 5+ year old compilers in Nixpkgs.

Fair enough. And if there would be a package that could absolutely not be built on a newer rust, they could create the symlink in their derivation anyways.

[mmlb]

This is an improvement over the status quo either way, but: this doesn’t adjust the fetchCargoTarball behaviour, which is good, but that means it’s still writing to the deprecated location. Doesn’t that mean we’ll still get warnings if we don’t mv or ln it in the build hooks? Do we not use those files at all somehow?

code comments say this only applies when depending on a git repo. I'm not sure if I built one of those explicitly, let me check (currently rebuilding everything as I ran a gc and did not cache any of this remotely ...)

Honestly I'm not sure why its not warning any more even without the mv or ln, as you suggest. I suspect it has to do with difference between $CARGO_HOME/config vs $CARGO_HOME/config.toml and where fetchCargoTarball writes the config to $name/.cargo/config. Looks like cargo is not warning about the latter case. I have a hunch that will change one day and then I'm not sure what we can do w/o causing the FOD hashes to be wrong.

[mmlb]

Rebased on latest staging to handle the conflict, looks like I'm rebuilding the world ...

[mmlb]

commitmsgfmt FOD hash checks out as no changes after rebase.

[emilazy]

I think let’s land this and worry about if the path in fetchCargoTarball affects anything another time. Thanks!