{buildRustCrate, defaultCrateOverrides}: remove

[niklaskorz]

Motivation and historical background

The buildRustCrate helper was introduced in 2017 by 5a0d954 for the purpose of allowing Rust packages created through carnix to be included in nixpkgs.
Similar to crate2nix, carnix generated a rather large Nix expression Cargo.nix from a cargo lockfile.

As carnix has been unmaintained since 2019, @figsoda removed it in #202394.
Ever since, buildRustCrate has been left in a state where it was exposed by nixpkgs, but nothing inside nixpkgs depended on it.
The tests for buildRustCrate were previously maintained by @andir, but have been left without a maintainer since 31e5b8d.

It is unlikely that packages using buildRustCrate would ever be allowed inside nixpkgs again, partially due to the size of such generated Cargo.nix expressions.
In fact, nixpkgs is currently in progress of removing all occurences of Cargo.lock, motivated by @Atemu in #327063 and enabled by the @TomaSajt with the recently introduced rustPlatform.fetchCargoVendor in #349360.

Considerations against removal

It is noteworthy that buildRustCrate is not without maintenance, seeing a few changes and improvements per year.
A popular solution for packaging Rust outside nixpkgs that depends on buildRustCrate is crate2nix, which allows building and caching every crate in its own derivation.
crate2nix's own docs state:

Since crate2nix heavily depends on buildRustCrate in nixpkgs, it makes
sense to hack on them together.

To be able to provide pull requests, you probably want to fork
nixpkgs first. Once you have done that,
clone that fork into some local directory (separate from crate2nix).

In this regard, it may be in crate2nix's own interest to continue maintenance of buildRustCrate inside their own repository.

Furthermore, there are ongoing discussions initiated by @emilazy in #333702 to package Rust crates separately, possibly encouraging leaving buildRustCrate in tree in case it will be needed to implement such a Rust package set.
However, since the introduction of fetchCargoVendor, the urgency of such a package set seems to have shrunk.

Required actions if this were to be merged

While buildRustCrate is not needed by nixpkgs anymore, it still is a vital part of the Nix Rust community outside nixpkgs, in particular because of the popularity of crate2nix.
It should either be moved to a shared repository inside https://github.com/nix-community/ or become a part of crate2nix itself.

Ping for other maintainers involved in buildRustCrate

(this list may be non-exhaustive)

• @Kranzes
• @flokli
• @kolloch

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/)
• 25.05 Release Notes (or backporting 24.11 and 25.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.

[emilazy]

We have other language‐specific packaging utilities in Nixpkgs that can’t be used in Nixpkgs (e.g., various modes that let you IFD a lock file). I’m not sure why this one specifically needs to be removed? But I don’t object to moving it to crate2nix, if nothing else is using it at this point.

[niklaskorz]

We have other language‐specific packaging utilities in Nixpkgs that can’t be used in Nixpkgs (e.g., various modes that let you IFD a lock file). I’m not sure why this one specifically needs to be removed? But I don’t object to moving it to crate2nix, if nothing else is using it at this point.

At yesterday's Nix Darmstadt meetup, I raised the question of what the usual procedure for build helpers not anymore required by other packages in nixpkgs is, and was encouraged to open a PR for proposing the removal, one of the reasons being to reduce bloat of the nixpkgs repository.
If the final outcome is a rejection of this PR combined with renewed interest in maintaining both buildRustCrate and defaultCrateOverrides in-tree, I am perfectly happy with that as well.

[niklaskorz]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 373744

---

x86_64-linux

⏩ 2 packages blacklisted:

• nixos-install-tools
• tests.nixos-functions.nixos-test

✅ 1 package built:

• nixpkgs-manual

---

aarch64-linux

⏩ 2 packages blacklisted:

• nixos-install-tools
• tests.nixos-functions.nixos-test

✅ 1 package built:

• nixpkgs-manual

---

x86_64-darwin

✅ 1 package built:

• nixpkgs-manual

---

aarch64-darwin

✅ 1 package built:

• nixpkgs-manual

[fricklerhandwerk]

Please don't simply delete old locations, but redirect them to release notes. That way whoever has a bookmark will instantly find the reason why the thing they were using is gone.

[flokli]

At yesterday's Nix Darmstadt meetup, I raised the question of what the usual procedure for build helpers not anymore required by other packages in nixpkgs is, and was encouraged to open a PR for proposing the removal, one of the reasons being to reduce bloat of the nixpkgs repository.
If the final outcome is a rejection of this PR combined with renewed interest in maintaining both buildRustCrate and defaultCrateOverrides in-tree, I am perfectly happy with that as well.

crate2nix relies heavily on both buildRustCrate and defaultCrateOverrides. Kicking this out of nixpkgs would mean Cargo.nix files generated by it would either need to also contain that code, or pull this from yet another repository. It might also accidentally break cross-compilation functionality, as refactors in nixpkgs might require updates to there.

I'm personally not a fan of this change, at least not without fully understanding the implications. In this form, it'll simply break all crate2nix-packaged projects on the next nixpkgs bump if merged.

[niklaskorz]

I'm personally not a fan of this change, at least not without fully understanding the implications. In this form, it'll simply break all crate2nix-packaged projects on the next nixpkgs bump if merged.

Thank you for the feedback, @flokli. Do you think an approach from the opposite direction, bringing buildRustCrate and defaultCrateOverrides into crate2nix before considering them for removal from nixpkgs, may be more acceptable? If so, I would be willing to work on such a PR and only bring back this one once we have found an acceptable solution.

Regarding the concern of having to bring in buildRustCrate into Cargo.nix from a source other than nixpkgs, this is already the norm for most "2nix" projects in the ecosystem, such as gomod2nix, cargo2nix or yarnpnp2nix.

[flokli]

I'm personally not a fan of this change, at least not without fully understanding the implications. In this form, it'll simply break all crate2nix-packaged projects on the next nixpkgs bump if merged.

Thank you for the feedback, @flokli. Do you think an approach from the opposite direction, bringing buildRustCrate and defaultCrateOverrides into crate2nix before considering them for removal from nixpkgs, may be more acceptable? If so, I would be willing to work on such a PR and only bring back this one once we have found an acceptable solution.

Regarding the concern of having to bring in buildRustCrate into Cargo.nix from a source other than nixpkgs, this is already the norm for most "2nix" projects in the ecosystem, such as gomod2nix, cargo2nix or yarnpnp2nix.

Moving it out of nixpkgs would mean crate2nix would need to start vendoring all this into every repo using it. I still think it makes more sense to keep this code in nixpkgs. At least defaultCrateOverrides can be useful for consumers other than crate2nix, and orchestrating things like cross-compilation fixes with nixpkgs while buildRustCrate doesn't live in there sounds like a lot of unnecessary toil.

Is it really so much of a liablilty to keep it in nixpkgs?

[Atemu]

The original premise was that this smelled like dead code of a builder that nobody within Nixpkgs uses for anything.

If it's actively used in this way, I'd rather keep it in Nixpkgs too.

This fact should be clearly documented though and I think the same people who maintain crate2nix should maintain that code.

[niklaskorz]

Alright, I will close this PR and refer to it if the topic comes up again. As keeping both buildRustCrate and defaultCrateOverrides in-tree appears to be the preference, I'll instead dedicate my time to improving the defaultCrateOverrides, starting with #374416.