Nixpkgs-multiverse: every version that ever existed

Links
21

This is cool but it’s not what they were actually asking about, right? It makes sense that it’s polynomial to answer the question “is it possible to satisfy this with exactly one Nixpkgs revision”, but I’d be surprised if it’s easy to answer the question “what is the minimum number of Nixpkgs revisions I need to satisfy this (could be more than one revision)”.

6 Likes
22

Good point. That is a SAT problem then.

4 Likes
23

New “fast” mode:

9 Likes
24

I love this!
But and please don’t take this as criticism, I can’t use it, not because I don’t trust you, I know you are a well-know member of this community and nix expert but I can’t add to my flake input something that is not under the nixos/nix-community gh org umbrella :slight_smile:
I hope again this not sounds against the project which is a half miracle for a lot of people

best wishes for the future of the project

1 Like
25

Why can’t you? Sounds like a trust problem.

2 Likes
26

Is this still true after Don't copy flakes to the store unnecessarily (maybe 3rd time's the charm) by xokdvium · Pull Request #15711 · NixOS/nix · GitHub (included in 2.35.0)?

They are lazily downloaded even before 2.35.0

I think I’m holding the fast version wrong, what’s going wrong here?

ulucs@MacBookPro:~/ > nix build github:fzakaria/nixpkgs-multiverse#legacyPackages.x86_64-linux.fast."967d40bec14b".python3
error:
       … while calling the 'throw' builtin
         at «github:fzakaria/nixpkgs-multiverse/4745826df4b3d554ea546d8a428767b790dd19da»/multiverse.nix:660:19:
          659|         # drvPath a fake cannot have, so the message says what to append.
          660|         drvPath = throw ''
             |                   ^
          661|           multiverse: ${drvName} is a fast fake derivation and has no drvPath — it

       error: multiverse: python3-3.8.9 is a fast fake derivation and has no drvPath — it
       substitutes by store path alone. Append the output: …python3."3.8.9".out
       (outputs: out).
       For override / nix develop / a real derivation, use .eval instead.

Ah, I had to manually target .out

27

Yea that’s an unfortunate thing right now with the .out – I have some ideas but they make flake show break; I’m still investigating.

If you use the mvs tool it takes care of it for you.

28

Feel free to fork it, audit it and run your own

29

nix-community isn’t particularly audited or even guaranteed to be maintained. It’s often where projects go to die.

2 Likes
30

Also the thing to be weary of are random substituters (caches).
If you trust “Nix is pure” then evaluation is safe*

except rare CVEs for escaping sandbox but /shrug those hit NixOS/ org just as much*

31

You might appreciate this now: nixpkgs-multiverse: the fewest nixpkgs | Farid Zakaria’s Blog

5 Likes
32

This is about to make my home manager very happy.

1 Like
33

We started a discourse topic (link on README and on the site) if you want to chat about the multiverse.

34

If you only “install” the packages, yes. (if I omit complications from the /run/opengl-driver/ impurity)

But if you overuse pinning, e.g. use this to build stuff, like a lockfile where you lock the version of each dependency separately, you’ll probably get into troublesome situations (including “conflicting” glibc versions).

1 Like
35

I still don’t get how multiple glibc will cause problems in Nix unless you are dlopen random things (which you should not do in Nix) ? No glibc versions should conflict for separate installables, that is by Nix’s design of RPATH.

Do you have a simple example?

1 Like
36

We don’t seem to index Neovim plugin versions, but if you pinned Neovim and used, say, blink.cmp that had a newer glibc, that uses Lua’s cpath to load a native library. There are cases where you have to dlopen things in Nix.

37

I agree. Nix is a power user tool. :smiling_face_with_tear:

2 Likes
38

Idea: could we get the latest version of Nixpkgs with a specific version of a package from the multiverse and use its package set? I guess we kind of have that since some wrappers for adding plugins give a package set to use, but may still be useful in some cases. May already have this, have not looked too closely at the docs.

39

That is supported already.

The API is very rich. You can get your nixpkgs through a lot of different composable selectors

(mv.at (mv.goneSince "python2").label).python2

(mv.at "26.05")

let
  mv = multiverse.multiverse.x86_64-linux;
  # newest revision the index knows, as a real Nixpkgs
  pkgs_tip = mv.tip;
  # by release — the channel as it stands today, backports included
  pkgs_24_11 = mv.at "24.11";
  # newest revision on or before that date
  pkgs_2022_03_15 = mv.at "2022-03-15";
  # by commit
  pkgs_dc460ec76cbf = mv.at "dc460ec76cbf";
in {
  packages = [
      pkgs_tip.python3
      pkgs_24_11.python3
      pkgs_2022_03_15.python3
      pkgs_dc460ec76cbf.python3
    ];
}
5 Likes
40

Heya,

This is so helpful that I would advocate to have this shipped/merged by default in NixOS/nixpkgs !

Thank you for this.

3 Likes