Flakes as a unified format for profiles

[iFreilicht]

@bobvanderlinden

See for instance https://github.com/NixOS/nix/pull/3573#issuecomment-625183478 and https://github.com/NixOS/nix/issues/3579#issuecomment-627360528. (Not linking them to avoid posting comments from DiscourseBot on GitHub)

Reading the latter one is actually a little discouraging, as it sounds like @edolstra specifically believes the multiple different versions of nixpkgs should be the default, and our idea for the optimized usecase shouldn’t be? Maybe I’m reading too much into it though:

Sure, but do we want to encourage users to have software install from 20 different versions?

Yes. That’s exactly what Nix was created for. If you’re happy with running software from one consistent set of packages, you might as well run Ubuntu.

But that whole thread in general is sooo interesting, so I’m linking it now as it seems very relevant to the discussion. For example, @domenkozar already had the same idea I posted and that is close to the export command you’re proposing:

I really think there’s only something like nix profile --init --user missing that would create ~/config/nix/flake.nix which would describe your user profile and you just keep adding packages.

And eelco corroborates my point that manifest.json is better than moving everything to a flake.nix:

By contrast nix-env and nix profile don’t need to evaluate previously installed profile elements; profile elements are closures in the Nix store, not expressions that need to be evaluated.

And later on:

We just need a command to recreate a profile from a JSON file (nix profile import or something like that).

There was even a specific issue created for this: https://github.com/NixOS/nix/issues/4482 Maybe you’d like to link that in your nix profile UX issue?

@bobvanderlinden

For me, the whole point of the nix profile cli is that it supports imperative commands. Familiar for newcomers. For advanced users it’s a more fluent workflow than editing a file.

That’s very true, but I think the declarative workflow could be made more fluent as well with something like nix profile edit, and this would ease the transition. But I do concede that this is an additional feature that we should work on after the current UX is fixed.

@bobvanderlinden

Adding names is both backwards-compatible as well as a relatively small change. It might not even need an RFC.

You’re right. I will try to implement this. I think it’s small enough to not have an RFC. In my mind it’s basically a bugfix for nix profile update vim not working.

I also agree with the rest of your proposed timeline. That seems to be a sensible and the quickest way of moving ahead with this topic.

@Ericson2314

I would support moving nix profile outside of Nix itself.

That does seem a little extreme to me.

I see what you’re saying; profiles in and of themselves are just symlinks to store-paths with a history you can rollback in, and there are many potential ways we could build imperative package management on top of that.

But I agree with Bob that Nix needs one first-party implementation of this concept. nix profile and nix shell are the most convenient ways to get started with Nix, and I believe we should keep that barrier to entry low. I will accept that this means it must be more conservative in its approach and changing it will be harder, but its existence doesn’t preclude other imperative tools built on top of it.

And hey, if my idea of a nix profile edit workflow doesn’t get consensus, I’ll happily make a PoC to prove how awesome it is out-of-tree. This gives more flexibility, and in the end, installing it will just be a nix profile install github:iFreilicht/betterNixProfile away