The Answer to the Original Issue

If channels were to be removed, it would be more clearer to everybody including new users, what the real use and power of nix is, and all documentation would go straight to pinning. Then only after understanding this, can people write higher level abstract tools to provide an auto-updating "channel" like interface to the underlying pinning concept.

One effect of this is that you get reproducibility. Note that this is not binary reproducibility, since it's still possible for the compilation of code to give different resulting binaries. But it is reproducibility within the context of Nix universe.

No pinning isn't about which channels you get. Pinning pins to a content addressed commit hash of nixpkgs or any nixpkgs even your own fork. Channels is orthogonal and probably a mistake and should be removed.

What's "pinning"? Is this ever explained to a new user? Where? (Yes, I understand what it is now, but new users probably will not, meaning it doesn't exist to them.) Your packages never get bug-fix updates Your packages never get security updates Broken package expressions never get fixed. If you need to update one package, you must update them all. This can be seen as either consistency, or limitation. It depends on the use case.

The main thing I want to accomplish is to distinguish between the versions of packages, and the versions of derivations.

What I want is to let a channel have several derivations for a package, each with its own version. This is current behavior. I then want my derivation to depend on a specific package name and version. Since versions are currently put into some package names, this is current behavior, though it would be cleaner to just use separate names. I then want my derivation to pattern match a range of versions. This is not current behavior. The current channel will provide a package with the greatest version number matched by the range provided that it has defined.

To summarize what I have read here (correct me if I am wrong) @mayhewluke described some real drawbacks of how derivations are currently implemented: Derivations cannot use a specific version of a package. Derivations are limited to a very small subset of real versions for dependencies.

You always have the option of adding missing versions of certain packages to your local database by means of an override as described in http://nixos.org/nixpkgs/manual/#how-to-create-nix-builds-for-your-own-private-haskell-packages. You can register aeson-0.8.1.1 in your copy of Nixpkgs without needing to change the Nixpkgs git repository at all.

So what happens if I have to fix a bug in an old project that was using 0.8.1.1? In that particular case, Nix won't help you and you are better off using a cabal-install sandbox or a stack build.

To be certain, you can just copy those by nix-copy-closure. Note that version numbers of direct dependencies don't contain all the information at all.

We keep multiple versions in nixpkgs only when there's a good reason to. Nix is able to handle any number of versions/configurations, but on the other hand it's much more convenient when all (or most) use just a single one. It leads to better sharing of the effort in many respects: simplified maintenance, testing, sharing of the binaries, etc. It's what most distros do. (Only gentoo diverges from the big ones I know, and they pay a price for it.) When we do create more variants, we just name them (attribute paths), e.g. gcc48 and gcc49 or ffmpeg and ffmpeg-full.