Flakes as a unified format for profiles

iFreilicht · June 22, 2023, 7:04am

Maybe this post should be an RFC, but I just have to collect my thoughts on this first. Feedback is appreciated. Does this idea have merit, or am I missing something big that makes this infeasible?

So I’ve been reading a lot through the issue tracker, particularly the issues on nix profile UX. There were some interesting ideas in there, but my overall conclusion was that most of them were mostly bandaids on system that just wasn’t that well designed to solve issues that were more basic.

I touched upon some issues around moving to declarative profiles myself, and I think there might be a solution here that was already started by @bobvanderlinden in `nix profile` pins nixpkgs per package · Issue #7964 · NixOS/nix · GitHub, but I’d like some broader discussion on it as it’s a big change.

Moving from manifest.json to a flake

Just to get this out the way, manifest.json will still be there for backwards compatibility.

The basic idea is that there is a basic flake that represents an empty profile:

{
  inputs = {
    nixpkgs = "xx-replace-nixpkgs-xx"
  };

  outputs = { self, nixpkgs }:
    let
      profilePackages = 
        { }
        // (with nixpkgs; { }) 
        // ({ /*more-inputs*/ });
    in {
      packages."system-tuple" = 
        profilePackages // {
          default = nixpkgs.buildEnv {
            name = "user-profile";
            paths = builtins.attrValues profilePackages;
          };
        };
    };
}

For this discussion, the system tuple is inserted during the creation of the flake, but is not an input to the flake.

When the user runs nix profile install for the first time (i.e. there is no profile-link yet), this will be the basis to create the 0th profile generation as follows.

The algorithm

Create a temporary folder and insert the basic flake from above into it
Replace “system-tuple” with “aarch64-darwin”, “x86_64-linux” etc. depending on the system
Replace “xx-replace-nixpkgs-xx” with whatever flake:nixpkgs resolves to (“github:NixOS/nixpkgs/nixpkgs-unstable” in the default global registry)
Lock the flake as with nix flake lock --update-input nixpkgs
Add the locked flake to the store with nix store add-path
- Let profile-0-flake-path be the resulting store path
Install the profile as you would with nix profile install path:$profile-0-flake-path, but instead of linking it as profile-1-link, link it as profile-0-link.

This gives us a basic profile that has no packages installed to it, with a locked nixpkgs input and a manifest.json that enables full backwards compatibility with the current tools.

Now, we proceed with the regular installation of the package. This will be the exact same for all future calls to nix profile install as well (except for the id of the generation);

Create a temporary folder again and copy everything from profile-flake-path into it
Separate installable like so: For nixpkgs#git, flake is nixpkgs, attrPath is git.
If flake is already in the inputs, go to step 14. Otherwise:
Add whatever flake resolves to to the inputs
Modify the flake by replacing // ({ /*more-inputs*/ }); with
```
        // (with $input-name; { }) 
        // ({ /*more-inputs*/ });
```
where $input-name is replaced with the name that was chosen for the input flake
Lock the flake as with nix flake lock --update-input $flake;
Modify the flake by adding the new attribute path to the correct set, inheriting from legacyPackages or packages. For nixpkgs#git on an M1 Mac, that is a string replacement of // (with nixpkgs; { }) with
```
        // (with nixpkgs; { inherit (legacyPackages."aarch64-darwin")
          git
        ;})
```
or of // (with nixpkgs; { inherit (legacyPackages."aarch64-darwin") with
```
    // (with nixpkgs; { inherit (legacyPackages."aarch64-darwin")
          git
```
Add the locked flake to the store with nix store add-path
- Let profile-new-flake-path be the resulting store path
Let the current profiles flake path be profile-old-flake-path
Remove the flake path:$profile-old-flake-path and install path:$profile-new-flake-path in a single operation

We now have a profile that is mostly backwards compatible with the current system, except that every input is only linked once. The generations are there as symlinks like before, the manifest.json is there (though it would contain less information), so rollbacks, list, history, all of that works like before. You wouldn’t be able to upgrade as the installed flake never changes, but that’s the only limitation in backwards compatibilitiy I can think of.

What this allows

We can now solve a number of UX issues with nix profile:

#7964, `nix profile` pins nixpkgs per package

As nixpkgs is now locked, additional calls like nix profile install nixpkgs#just will only add an attribute to the flake. There’s no implicit update and no re-downloading of the whole of nixpkgs. Explicit upgrading can still be made possible, but the algorithm for that is out-of-scope of this post. There’s also the question whether inputs of flakes should automatically follow existing inputs. This might be desirable, but I’m not sure about potential downsides.

#1807, First nix-env invocation is not reversible

We now have a 0th profile generation with an empty profile that you can always go back to and start anew from without having to manually create a new profile, installing a package into it and then manually creating symlinks in your old profile.

#7965, profiles are hard to reproduce

You now have access to the flake that built the profile and can just pull it out from the nix-store. A simple nix profile import command that skips most of the steps of install and just executes the installation step directly would be a potential import mechanism.

#5587, `nix profile` allows installing duplicate packages

Through the semantics inherit, trying to install a duplicate package will fail. The semantics of // ensure there is always one clear candidate for a package, even if there are two attributes with identical names in different flakes. Which one is chosen depends on the order in which the flakes were added to the input, which should be fine in most cases, but using a union function that fails on duplicate keys would be a simple solution. Maybe there is one in builtins or lib already?

#7967, `nix profile` entries need stable identifiers

The identifiers are the names of all the flake outputs, minus default. These are guaranteed to be unique. This in turn solves #7960 and #7961, and also allows solving the next issue:

#7962, `nix profile` counter-intuitively uses regexp to match packages

Instead of matching against the full attribute path of an installable, match against the identifier. In most cases, this will be sufficient, and the logic doesn’t need an extra case for regex.

`nix profile list` is not helpful when installing from a flake with `pkgs.buildEnv`

I didn’t create an issue for this yet, but during my experiments with a declarative profile, I found that while using a flake as the basis for your profile is a great strategy, it’s not supported well by the current tools. Making this the default approach for profiles would allow us to change nix profile list to recurse into the profile flake and list all the installed packages.

We can create a proper transition flow from imperative to declarative profiles

This came up in the discussion below. Right now, most of us agree that just using nix-env for managing your packages is suboptimal, but in user profiles, there’s no good alternative. With the flake-based profiles, we can implement a nix profile edit command, that basically copies the current flake from the store to a temporary directory, runs nix edit on it, allows you to edit the flake, and then proceeds like install usually would.
This makes it very easy to try out declarative package management, and once you’re comfortable with it, you can copy the flake from the nix store and version-control it yourself.

What next

I feel like this could be implemented as a basic prototype with string replacement and calling existing nix commands in a basic bash or python script. I’ll try to do that soon, maybe I’ll find time on the weekend, but for now I’d just like to hear your thoughts on this. It seems like an awesome idea, but also a little too good to be true. What did I miss?

bobvanderlinden · June 22, 2023, 9:16am

Thanks for posting this! Good to see more people are interested in improving the nix profile/nix-env situation.

I have also thought about this. Basing a profile on flakes was also my intuition as the right way to go. However, it there are some side-effects of doing so.

For instance, if you want to upgrade a single package, you’d need a whole separate input of nixpkgs, so that nixpkgs is pinned for that specific package. This is a feature that is currently already in nix profile.

Same for installing a new package, it’ll be based on the nixpkgs version that is in the inputs. It won’t be the most recent version.

Now, is this a feature/mechanism we’d like to keep and should be supporting? I’m not sure. I personally think you’ll run into problems when different packages vary widely in their version. Trouble like one package being based on glibc-X the other based on glibc-Y can cause issues as runtime. I would indeed opt to drop support for this, as I’ve written in `nix profile` pins nixpkgs per package · Issue #7964 · NixOS/nix · GitHub.

However, I do think there are people who want to keep supporting such a feature. This makes dropping it a bit controversial. Since profiles are already here and we’re talking about backwards-compatibility, I think a small step that solves most of the issues surrounding the bad UX of nix profile is to add names/slots for profile entries, like I suggested in `nix profile` entries need stable identifiers · Issue #7967 · NixOS/nix · GitHub. It is a small change that can improve the UX quite a lot already: add a name to each profile entry so that cli can use the name as an identifier instead of an index.

That said, we can drop backwards-compatibility if we migrate the current manifest.json to something else (like a flake file). This also happened when Nix moved from nix-env to nix profile: it’ll convert the current profile files to use the ‘new’ manifest.json structure. If we opt to do so, we don’t have to keep manifest.json around and maintain it. The current manifest.json is part of an experimental flag after all

I’m worried that if we’re going to make the step to flakes it’ll likely result in quite a bit of discussions on the structure of the flake file.

iFreilicht · June 22, 2023, 10:47am

That is a good point. So let’s talk about it.

I strongly believe that nix profile (currently nix-env) is the easiest interface of nix to understand for new users. It works almost exactly like the package managers they know, except with the added benefit that they can use it on any platform, it has the latest versions of everything and is completely independent from your OS’ repository or release upgrade process. This means we have to consider what the default use-case is that we’re debating here.

And as the default, there seems to be very little harm in upgrading the full flake instead of just one attribute path. It might be surprising, which is a little unfortunate, but we can notify the user, list all the packages that will be upgraded and ask for confirmation. On the other hand, it actually has benefits:

The interface and the semantics are easy to understand.
Profiles don’t become complicated and bloated over time.
The user’s software stays up to date, which can be a security benefit.

There is a slight risk that upgrading all packages will break one that the user relies on. I don’t know how often this happens, but especially for stable releases, this should happen very rarely. If the user doesn’t need the upgrade, they can just nix profile rollback. Maybe they will even write an issue.

If the user does need both an upgraded version of a package and a downgraded one, I think the default is still good: upgrade everything, downgrade the one thing that is broken. This is still possible with this interface, as a user can nix profile install github:NixOS/nixpkgs/23.05#randomPackage, which then adds the stable version of nixpkgs as a new input. If a user is particularly keen, they might even add that to their flake registry first as an alias like stable. This should be something we educate users on when explaining the basic functionality of nix profile, it is part of the basic functionality.

Now there are absolutely some more advanced use-cases, but I think for those we should 100% encourage users to drop the imperative interface and to move to a declarative one.
For this, I would implement a nix profile edit command, that basically copies the flake from the store to a temporary directory, runs nix edit on it, allows you to edit the flake, and then proceeds like install usually would.
This makes it very easy to try out, and once you’re comfortable with it, you can still move the flake out from the nix store and version-control it yourself.

I agree, but I think there’s no reason for just a small change. The nix profile UX is bad, and we should fix it fully. As you say, all of this is experimental, so backwards-compatibility only requires graceful failure and the ability to upgrade and roll back. I didn’t actually know that manifest.json was part of the new CLI.

I don’t care. I’m ready for it. I want the new CLI to work well, to be easy to use and to be stabilized, so that I can show it to clients and say “look at this, this is the solution to our problems.” And if that means discussing for a week whether it’s ok to use with ; in there even though it’s kind-of considered bad practice, so be it.

Nix is so amazing and the UX just holds it back immensely. We need to make it better.

Famous last words before I burn out in half a year

alper · June 27, 2023, 5:06pm

Flakes are extensible with whatever output you would want to add there, or?

This is generally a problem with flakes in general I find but maybe it should be a bit awkward to do this (but possible) to discourage people from having too widely diverging versions.

This is ‘the homebrew to nix pipeline’ and yes it should be iterated on.

Just giving the installed packages humane names and not allowing them to be duplicated would already be a huge boost here. Once that is in place, we can talk about migrating this entire thing to a flake format?

iFreilicht · June 27, 2023, 6:30pm

Yeah, I agree. There are genuine usecases for this. There’s multiple solutions already:

provide a full flakeref like github:NixOS/nixpkgs/2937mdowpld…#vim
override what nixpkgs resolves to with --override-flake
add a second entry like unstable to your registry

The important part is to handle these properly, even when the default is to deduplicate.

Yes, absolutely. Now, after having some distance to this idea, I feel like @bobvanderlinden was actually very accurate with his analysis and feature requests.

You know, in the light of RFC 136, I think that might take a while. I think it could be interesting as an experimental frontend, but flakes are not the only installables, and supporting different ones well in nix profile will be easier with the manifest.json as the primary representation of the profile’s contents.

Maybe maybe, at some point, flakes will be so uncontroversial that a step like this can be taken. But for now, I’ll try to improve the UX we already have.

bobvanderlinden · June 27, 2023, 9:24pm

You do not need to convince me. I’ve already stated in `nix profile` pins nixpkgs per package · Issue #7964 · NixOS/nix · GitHub that I would opt for a single input for multiple packages. I think we’re saying the same thing. I fully agree it would be better.

The point is that there are probably other people who want to keep supporting such a feature. You’ll need to convince that part of the community (or at least the ones participating in the RFC).

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)

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.

We can already declaratively handle packages. Just create a buildEnv package. You can create a template and users can use it already with a local file. Next to that method, we have nixos, home-manager, devenv, devbox, etc, etc. These all require a edit-file workflow, which isn’t very familiar for new-comers and isn’t as fluent.

I’d like to make this feature and get it out of experimental phase asap. Flakes are still experimental, it was introduced as experimental ~5 years ago(?). I want to pick the parts that we can already agree on and let let the controversial parts be a separate discussion/issue/experimental-feature.

Nix as a cross-platform homebrew/apt/pacman/winget alternative is already huge(!). Those people will not care about what kind of structure is used to store which packages are installed. You could even argue that JSON as the backend file is easier to grasp for new-comers.

Indeed. I think almost all of the UX issues can be worked on once we have names in the manifest. Adding names is both backwards-compatible as well as a relatively small change. It might not even need an RFC.

After that we can make the following work:

nix profile install github:nixos/nixpkgs/nixpkgs-unstable#vim
nix profile update vim
nix profile remove vim
nix profile update # update all entries

And stabilize these CLI commands. Before stabilization we could also decide to drop support for:

nix profile remove '.*'
nix profile update 1

And maybe introduce:

nix profile remove --regex '.*'
nix profile update --index 1

(Personally I’d prefer to just drop these features until people actually find use-cases for them that aren’t covered by the above commands)

An RFC is probably required for the nix profile CLI choices. I’m already in conflict myself while thinking about what should be supported . I think that getting consensus about the CLI is not easy and a huge win already.

We can stabilize on the nix profile command and its UX. The backend could still be debated on separately. I think(/hope ) the UX doesn’t need to change when the backend changes.

When that’s settled we could look into export/import functionality as a first step towards supporting flakes. It could for instance export different types. I think it could be a good steppingstone for an manifest.json alternative. It’ll be easier to talk about this as a export/import first before replacing the manifest.json backend with flakes. Flakes as a base is especially debatable as there isn’t a good solid foundation in Nix itself to make changes ‘imperatively’ to .nix files. This is needed if we want to base profiles on flakes. It’s possible and there are some third-party implementations that can do so (like nix-editor), but I wouldn’t call it a solid foundation that’s easy to integrate into the Nix CLI itself . (nix-editor is great regardless though!). I think that’s where a lot of the debate will be surrounding on.

Let’s not do that Agreement on a small step (like nix profile UX) would probably still take months. I’m trying to avoid the discussion multipliers and end up with years

Ericson2314 · June 28, 2023, 2:56am

I would support moving nix profile outside of Nix itself.

If nothing else, there are multiple completing visions for what the proper “profiles” user experience should be. But the core profiles mechanism, as I’ve tried to document in Clean up and fix manual on profiles by Ericson2314 · Pull Request #8531 · NixOS/nix · GitHub is just version control / rollbacks, and doesn’t care about any of this stuff. We can just expose that core functionality, and let out-of-tree projects compete who can do the best thing on top.

bobvanderlinden · June 28, 2023, 5:48am

Are you implying removing it from the Nix cli?

I personally think it’s an essential part of the Nix cli. It is used especially by newcomers to install other tools. Not just because they are used to the UX of imperatively adding packages. More importantly: what other lightweight options do you have to install other packages on Ubuntu/MacOS?

Long-time Nix users usually have little interest in nix profile. They’re already used to editing files to add packages and do not really seem to mind.

I’ve once made a proof of concept for a imperative workflow with declarative files: GitHub - bobvanderlinden/pocnix: A proof-of-concept cli for Nix
I haven’t completed it because: who’s ever going to use it? This is a feature for newcomers. Newcomers need to use nix profile to install pocnix.

It’s why I’m rooting for minimal changes to nix profile to make it workable. People should be able to install, update and remove packages. I don’t even care about version control and rollbacks. After that, yes, it’s fine to let some tools compete to get a better grasp of the problem space. As long as those tools can be easily installed and updated using Nix.

iFreilicht · June 28, 2023, 8:22am

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?

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.

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.

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

alper · June 28, 2023, 11:34am

I’d help in any way I can here. I agree that this is essential hygiene for what is currently effectively a broken command.

Ericson2314 · June 29, 2023, 1:17am

It is used especially by newcomers to install other tools. Not just because they are used to the UX of imperatively adding packages. More importantly: what other lightweight options do you have to install other packages on Ubuntu/MacOS?

Long-time Nix users usually have little interest in nix profile. They’re already used to editing files to add packages and do not really seem to mind.

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.

So we agree that nix profile is more for beginners than proficient Nix users. Great, that’s a good start.

Still, there is an implicit decision here that beginners should be able to learn Nix by itself, but what is the basis of that decision? Why can’t the learning journey of Nix be via downstream tools that specialize for specific use-cases and are therefore able to hide details / make simplifying assumptions?

I, as a member of the Nix team, would love to offload this stuff to you two, and whoever is else interested. I rather polish and refine the core (which is badly in need of these things), and delegate responsibility on this stuff to others who have interests and motivation unlike myself.

In fact, I would say that:

Reference documentation people and core functionality people should work together — i.e. refine and document the core in tandem
Learning journey documentation and add-on tools people should work together — create the beginner tooling and the curriculum around it at the same time!

I think making the “principle division” core vs periphery, and the “secondary division” coding vs docs, would be much more productive than what we have today (which is the other way around).

iFreilicht · June 29, 2023, 9:11am

100%

That’s a good point, I guess I want it to work that way because that was my experience. And it wasn’t great, so I want to improve that experience, but didn’t think that there might be an alternative user journey altogether.

I am somewhat concerned about fragmentation and confusion, though. Nix is already confusing and it’s hard to know where to start, so I feel there should be one ~official source or guide that even the Nix website refers to. I guess this is what you mean by “learning journey documentation”, and I suppose that is what nix.dev is supposed to be at some point, but it’s not there yet.

Thinking about other projects like nodejs or python, they have something similar where there’s one official tool (npm and pip) that is maintained separately, and other 3rd-party ones that are able to iterate more quickly and break compatibility more (yarn and poetry). So I absolutely understand that splitting these projects up might improve velocity, and it would certainly prevent different levels of abstractions from mixing, both of which are good things.

I am somewhat wondering whether nix profile is the only thing that would go this way, or whether other “periphery” tools like nix develop and nix shell should follow suit. It seems like you at least need some basic functionality in the base installation so that users can bootstrap their toolchain easily.

Yes, that sounds great, and is aligned with an (admittedly idealistic) option I’ve been thinking about; obviously this makes no sense for the core functionality, but for the periphery, writing a draft of the onboarding documentation first and then implementing the functionality based on that.

Yeah, thinking about it, that might make development as a whole much more sustainable.

One thing I am curious about is what you would suggest the interface between core and periphery to be. I think you argued for a genuine API before, but that comes with a maintenance burden. Maybe a stable CLI could be sufficient?

iFreilicht · June 29, 2023, 9:17am

Thank you! I think most effort would be spent in testing. Should be relatively easy, I’ll just fork the repo and let you try it out.

bobvanderlinden · June 30, 2023, 9:37am

I had a conversation with @fricklerhandwerk, but it’s probably better to share it here too.

I’m still unsure how third-party tools could realistically be the starting point. If Nix isn’t the starting-point, should these third-party tools all have an embedded installer for Nix (like Flox does?). That would cost quite a huge effort for third-party experiments. Flox has backing of a company with (I imagine) multiple people working on it full-time. How is that realistic for a third-party cli as an experiment?

To give an example where I’m already seeing this: devenv.sh. Also a third-party cli. However, it doesn’t come with a standalone installer. We got multiple people asking for help on upgrading devenv, because Nix profile has such a bad UX. Those were collegues and people on the devenv discord channel. It was at that point that I created all of those Nix profile UX issues: people depend on them when using devenv.sh.

To give some context, this is the “Getting started” page of devenv:

Of course, anyone that installs Nix using the (seemingly better maintained) Determinate Systems installer will automatically use nix-command and thus nix-env will direct people to use nix profile. Using nix profile install is fine, but then people want to upgrade (or switch from stable branch to main) and you’ll run into trouble.

How should a tool like devenv.sh handle this? It is already patching Nix itself to workaround some of its issues, but devenv.sh doesn’t ship its own nix-daemon or expose its patched Nix cli. I’m glad it doesn’t, as I think it would bring more chaos to the Nix ecosystem.

iFreilicht · June 30, 2023, 10:20am

Haha so I thought this wasn’t a problem and started writing my reply:

Couldn’t they just be in nixpkgs? Or, with flakes, the “official” one could be in the registry and a user could simply install it with…

Well. With what? You could use nix shell, but maybe that is considered too high-level as well and gets removed.

So what we’re (and I think @Ericson2314 specifically is) talking about is the store-only Nix, that has almost no user-facing commands except for what directly interacts with the store and derivation building, and everything else built on top. Which makes sense from a software architecture perspective, but not from a user perspective.

But maybe, nix profile could be a separate project and not third-party? If it was first-party, inside the NixOS organization, and the nix installer by default installed nix plus the first-party porcelain commands, we would get the benefit of easier development without any fragmentation or confusion.

I think it would still have to be a subcommand of nix itself, though. There was a related comment pointing out that git allows for something like this, but I get that this should be a carefully controlled change.

But basically, this gives us the best of both worlds: Fast development on the UX with barely any additional load on the core development team, and a coherent first-party learning journey that can be documented well.

There are some risks associated with this. Duplicated solutions for multiple different frontends like shell and develop, incompatible and inconsistent CLI flags and semantics of installables, stuff like that.

iFreilicht · July 9, 2023, 10:02pm

@alper @bobvanderlinden I finally got around to this! See my draft PR #8678.

You should be able to try it out like so:

nix shell -i github:iFreilicht/nix/profile-names-instead-of-index

This will take a long time as it builds nix locally, but I didn’t have time to set up a binary cache for this. The -i is important, otherwise your local install of nix will be used. Alternatively, if you already compiled nix locally from the repo, you can just pull my branch and rebuild, that will be much quicker.

Please give feedback in the GitHub issue so it’s properly tracked

bobvanderlinden · September 15, 2023, 8:35pm

I’d like to resurrect this topic. The PR #8678 is already a huge improvement. It resolves my main gripe with the current CLI: using shorthand names is possible for nix profile install, but isn’t possible for remove and upgrade. Stable identifiers for nix profile will unlock a number of potential other UX improvements.

It would be really great to get some reviews from one of the Nix maintainers.

Thanks @iFreilicht for your work so far!

9999years · October 30, 2023, 7:55pm

I think this is a great idea. In the meantime, I’ve created a nix profile manager called home-mangler, which allows installing a set of packages from a flake into the Nix profile. (And also handles updating inputs for the flake and removing the old packages when updating.)

iFreilicht · November 8, 2023, 9:09am

Oh, that’s cool! I looked at it now, but there’s basically no docs and no examples, so I’m kind of struggling to see what the UX of this looks like