search

solson / rust-nightly-nix

A Nix expression for nightly Rust versions
Apache License 2.0
40 stars 7 forks source link

Add Support for the Stable Channel #11

Open ethanpailes opened 7 years ago

ethanpailes commented 7 years ago

It would be nice to be able to use rust-nightly-nix to get non-nightly release channels as well. Obviously it is currently possible to just use the rust packages that are in nixpkgs, but it would be ideal if the compiler toolchain could be scoped to a project. I have done a little fiddling around, and at first glance the changes seem to be pretty easy.

Right now the answer when someone asks how to get rust-stable through nix, has just been to grab the version from nix-pkgs, so I should probably explain why I feel like it is worthwhile to have support in rust-nightly-nix. Right now if you have a default.nix for a project that includes rustc in its build inputs, running nix-shell will give you a different version of rustc depending on which nixpkgs you have. rust-stable releases every six weeks right now, so it is a pretty quickly moving target, and it would be good to be able to easily take a snapshot of the exact stable version that you want. Then you can do whatever you want to nix-pkgs and not have to worry about how it will impact rust projects.

My first crack at this is here: https://github.com/ethanpailes/rust-nightly-nix/tree/stable-support

If this seems worthwhile, I will open a PR.

Havvy commented 7 years ago

I'd like to see every Rust stable version in this repo TBH. Make it the premier source for anything complex w.r.t. Rust and let nixpkgs just handle the basic stuff.

ethanpailes commented 7 years ago

I'll try to find time to do some more thorough testing of my changes before I open a PR.

Ericson2314 commented 7 years ago

I'm actually kind of against this. Nixpkgs should be the default goto, and its an unfortunate that this repo needs to exist (note I am not wishing nixpkgs would change its policies regarding pre-built binaries etc---this is the unfortunate outcome of that IMO correct choice). For the determinism concerns @ethanpailes brings up, either we can add more stable releases to nixpkgs, or projects can pin nixpkgs. Both those approaches have precedent with other languages.

What @solson and I have talked about before is sharing code between this and the bootstrapping code in nixpkgs, https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/rust/bootstrap.nix. Then this would just be filling in the impure default arguments (date and hash).

But that does mean either exposing more than is necessary in nixpkgs, or fishing things out with an awkard callPackage <nixpkgs/pkgs/development/compilers/rust/bootstrap.nix> or similar. Feel free to convince me further that adding stable to this is the right choice.

solson commented 7 years ago

I'd like for an easy way, for developers and not packagers, to install any version of Rust from any channel (so I would include beta, too). This makes it easier to do things like test how code compiles under any out-dated version. It also allows getting a new Rust release immediately without waiting for a channel update.

I think packagers have different priorities and nixpkgs itself should never explicitly support many different Rust versions, though it would make sense for it to contain much of the generic code it shares with this repo.

solson commented 7 years ago

Note that in general I support making the implementation of this repo as minimal as possible by moving generic functions into nixpkgs. I'm interpreting this issue as a desire for a particular interface (being able to easily tell nix to install something very specific, e.g. rust beta 1.4 with an arm stdlib) in lieu of rustup, which provides this ability for nearly everyone not on NixOS.

Ericson2314 commented 7 years ago

Hmm, that is convincing :). Also I realized that making this support stable does not affect the degree to which code can be shared with Nixpkgs. Stable is used to bootstrap stable, so Nixpkgs needs to download stable binaries anyways.

ethanpailes commented 7 years ago

Adding stable support required making very minimal code changes, so I don't think implementation complexity is much of an issue.

With respect to pinning nixpkgs, I'm not familiar with the standard way to do that in a single project. Adding a git sub module for the whole nixpkgs tree seems kind of heavyweight.

From my perspective, having a single file that I can drop in to a new project and check in to source control to get a nice self contained sandbox is really nice. I believe that a software project should do its best to close over all dependencies, and the compiler tool chain is definitely a dependency. This sort of lightweight sandboxing is one of the primary promises of nix. I understand the desire for a central package tree, but I think package management with respect to software projects is and ought to be fundamentally different than package management with respect to operating systems.