That’s an implementation detail the user don’t has to see if it don’t improve the user experience.
Like said earlier, i want a concept for a user-friendly package manager that has the features of Nix. I don’t care how we implement that later at this point. How parameters are used should be easy to change. That’s the perspective i want us to have when discussing this.
In the flake world, this command runs the default package from the “hello” flake.
That’s how it’s implemented now, but we can change that. See it as a completely different program.
If you want a command to “run the default package from the “hello” flake”, it would look like this translated from my concept above.
nix run --from hello
There is no default channel like nixpkgs (in fact there are no channels anymore).
I don’t know the term in your current implementation, but you probably understand what behavior i expect from the commands. Like it should be obvious with good UI design.
I could just write a wrapper:
flake = 'nixpkgs'
You probably can do that in C++ too That’s not the hard part here.
The feedback i would like to get from the community is:
- Do you consider the UI concept intuitive and easy to use?
- do you see a way to improve it?
- Are there use-cases that i have missed (scope here is specifying packages, versions, “channels” (NixOS releases with updates), flakes)
The next step would be to implement a script to generate nixpkgs-all-versions-index data and put it into an ElasticSearch. And create a wrapper for Nix that has this UI. Then wen can try out how it feels. I could just go to people and ask “I have a package manager here, can i show you how it can install packages”. And see their reaction when we actually have 50 versions of ansible for example. And let them play around with it. See what questions people habe “how can i do X?” and where they get stuck. They should say “This is amazing, i want that!”
If this test is sucessfull and the community likes it, would you accept a PR to Nix that implements it, @edolstra?