Using the stable rust compiler for buck2
- Dominant language
- Rust
- Stars
- 4.4k
- Forks
- 394
- PR merge metrics
- No merged PRs in 30d
Description
What would it take to allow buck2 to build with a stable rust release? A recent contribution to Nixpkgs is trying to add a buck2 package. It's a fork of my package from buck2-nix. See https://github.com/NixOS/nixpkgs/pull/232471 for that.
But specifics of that PR aside, there's something of a rather large nit to pick: buck2 currently requires a very specific nightly, but this is problematic for various reasons in the upstream Nixpkgs repository. Notably, we try to pick exactly 1 stable compiler to use for all packages[1] in an ecosystem by default, including Rust. We don't package every nightly rustc build in Nixpkgs or anything like that; you can *achieve that* with third party code, like I do with buck2-nix. But that code is decidedly not upstream and for good reason.[1] This is not a Nixpkgs specific phenomenon either — any application that requires nightly will require downstream package managers to figure out a solution for this if they want to ship it to users. We work around it with a gross hack of exporting `RUSTC_BOOTSTRAP=1`, but this isn't an ideal solution and I don't like perpetuating it unless all else fails.
I realize Meta doesn't have these restrictions for stable versus nightly and my (perhaps misinformed) impression is that using nightly features is generally considered OK; after all, you can migrate things more rapidly and effectively thanks to the monorepo, you pin versions, you have refactoring tools, etc. But this would be nice for outside consumers.
If it's mostly a matter of "We didn't think too much about it, and nightly features are convenient, but would accept patches to target stable" then that's perfectly OK and something that can be worked towards. I'd be happy to write patches to try and help that. But if there's something preventing that on a technical level it'd be great to know, at least.
---
[1] You may have heard of Nix and be thinking "But isn't a major benefit of Nix that it allows you to use multiple versions of a single package?" Yes, and there are good reasons to do so. But doing it inside the core "standard library" of Nix code that ~everything depends on is a *bad idea* for many reasons we've found and for consistency and ease of use, it's easiest to just say "The default version is X, everything is built with X, you can use Y if you specifically choose it on a global or case-by-case basis."
Contributor guide
Assessment
This issue has not been assessed yet.