The nixpkgs are managed via the nixpkgs github repo which contains only a specific version for each program.
For example when I want to install the Ultimaker Cura program, I install it by adding “cura” to the list of installed packages in my configuration.nix file.
It then downloads and installs the version which is defined in the nixpkgs repo of the current channel, in this case this is 4.13.1, while version 5.7.1 is the most recent one.
Okay, this may happen because the maintainer did not update this program but even when he would, then there would still be only one specific version in the nixpkgs repo.
Why is it designed like this?
What if I want to install the version 5.0.2? I could do that by writing my own derivation but I probably could not contribute that to the nixpgs repo, could I?
In my mind it makes perfect sense to have as many versions as possible inside of the package repository, why doesn’t nix allow this?
Or are there other ways to accomplish this which I am not seeing right now?
If you want to install an old version that has been packaged in the past, you can just find the Nixpkgs commit with the desired version and use that (you could use nix-versions or nixhub to search past versions). So there’s no need to keep old versions around since you can always go back.
If you want a specific version that was not packaged, you probably will need to do the packaging yourself. It’s not the goal of Nixpkgs to have every single version of every package available that there ever was.
Not always – we package ten different versions of gcc (every major version from 6.x onward, plus both 4.9 and 4.8).
But, in general, nixpkgs has deletionist tendencies.
Yes, it’s possible – by analogy to the way we do multiplatform support – we don’t have separate pkgs.ffmpeg-x86_64 and pkgs.ffmpeg-aarch64, so we shouldn’t have separate pkgs.ffmpeg_4 and pkgs.ffmpeg_5 either.
The following comment explains how, and includes a fully-worked example (gcc):
Let’s say I do that and package my specific version. If that is an older version than the current one in nixpkgs, I probably could not push it to the main repo.
Therefore a maintainer “locks out” every version between the current one and the one that is about to be added right?
So my feeling currently is that there are many private nixpkgs repos with all kinds of programs and program versions which will never be distributed because of that…
That would be correct. Unless there is a good reason to package an older version (e.g. the newest one dropped hardware support or some important dependencies only work with the old version) there is usually only the most recent version in Nixpkgs.
I also don’t see that as a big issue. It’s the same model that most distributions have and if there was a huge demand to regularly have older versions available, beyond what is in the Nixpkgs history, people would go ahead and solve the issue. However, I assume in >99% of the cases, people want the newest version or one of the older ones is good enough. If you officially provide all these old versions, you also need to support and maintain them which would be a stretch for maintainers which already aren’t exactly under-worked.
No, it’s different. If you install from old nixpkgs version, you’ll get old everything. (security bugs in dependencies, etc.)
There would be inherent cost in maintaining multiple versions/variants. And I’m not even considering to build and distribute binaries of them, and combining them in arbitrary ways (say, non-default version of some dependency of the package).
one can in fact source multiple versions/branches/forks of nixpkgs in their config so as to mix and match versions.
if you’d like a way to do that without having to think about nixpkgs revs, you can check out devbox, which handles those bits for you under the hood.
Doable to support ranges which is what https://spack.io/ does;
You could in either also flatten every nixpkgs commit into a single mega Nixpkgs tree (diabolical)