Rename 'nix flake {command}' to 'nix {command}'

[hugosenari]

Is your feature request related to a problem? Please describe. Some UX problem

Explain what a flake is to someone that came from other package manager, where most of what flake commands are, is just what any language package manager does.

ie.: Nobody runs npm flake lock, or cargo flake check, etc

Describe the solution you'd like

Flake to be so integrated and transparent, that no user knows about its existence

Describe alternatives you've considered

Create a bash script called flake, that works as alias to nix flake (and some other nix commands), bundle it with nix installer in a file called flake.tar.gz and tell users they aren't using nix anymore, but "flake - the package manager"℠.

Additional context

I'm expecting conflict with current commands.

Priorities

Add :+1: to issues you find important.

[iFreilicht]

This works for some commands, and some are already use flakes/installables transparently, like nix build, nix develop, nix run etc. For these commands you are absolutely right, you don't need to know what a flake is.

And I think maybe some nix flake commands could be made general-purpose. nix flake show for example might become a command that you can apply not just to flakes, but store paths, expressions, any nix file and it could tell you what that thing is and what it contains. If that were to ever happen, it should of course be called nix show.

But nix flake lock (and almost every other nix flake command) only makes sense when applied to a flake, not when applied to any other installable, and when you use them you have to know what a flake is. There's just no way around that IMO.

Just like nix profile or nix store, nix flake is one layer of nix, and these layers are separate because you don't need to ever touch one to use the other.

[hugosenari]

@iFreilicht if you would create a new package manager today with .nix (or nickel) language, lock file, dependencies declaration (~flake~ inputs), artifacts definition (~flake~ outputs).

How would be your command to 'boilerplate' a new package?

• ifreipkg init, or
• ifreipkg fluggaenkoecchicebolsen init

What is fluggaenkoecchicebolsen?

• For our context are a new set of features that let us create lock files, standardize project.toml (python has no fancy name for it) or caching .nix evaluation, and other things.

Why fluggaenkoecchicebolsen?

• Because is a reference to a movie.

What does it have to do with package management?

• Nothing, but is funny

There is no such flake thing, it is just nix, we as older users need a codename to differentiate nix with some features from nix without that.

Now, we got attached to it, but push this confusion to new (and older) users isn't helpful.

I see some reasons to keep flake separated commands.

• Flake commands are unrelated to package management/creation.
• Flake is an extension to nix or installation would never be expected to be default, means it isn't an experimental feature but an experimental addon.

_{^{I almost forgot to mention that your package.nix or project.nix for ifreipkg have to be called fluggaenkoecchicebolsen.nix but it is another ticket ;-)}}

[iFreilicht]

That was a fun answer, but I think it's an oversimplification as well, and you didn't respond to a single one of my arguments.

if you would create a new package manager today with .nix (or nickel) language, lock file, dependencies declaration (inputs), artifacts definition (outputs)

Sure, if I wrote just a single package manager for just the purpose of providing software dependencies in a software repository, I might choose a simpler UI, like many others (yarn, npm, pip, poetry, cargo, heck fpm even) have already done. But when that package manager also handles system-wide installed programs (apt, pacman, dnf, yum), per-user installed programs (flatpack, snap, 0install) building those programs (portage, emerge), and handling a low-level depedency graph and cache access (rpm, dpkg), I might run into issues with my commands being too generic, or I have to create a separate CLI for every one of them, which is what Nix previously did.

If you have too much functionality on a single commands, you end up with ambiguities; What would nix add add to what? What would nix install install where? What does nix update update? What do nix new and nix init create?

As I said, this could work for some commands, and I'm open for discussion around that if you have any specific ideas for commands that should be generalized to operate on more than just flakes.

Now, we got attached to it, but push this confusion to new (and older) users isn't helpful.

That is conjecture. Additionally, flakes are not the only way to do package management or environment setup in Nix. You still have the old-school bare expressions in nix files, and the "new way" of doing things needs to have some name to be able to differentiate it from the "old way" to communicate properly. "Flakes" is such a name. Whether it's a good one is a different argument, but at least it's shorter than fluggaenkoecchicebolsen.

I see some reasons to keep flake separated commands.

• Flake commands are unrelated to package management/creation.

I would go even further; flake commands are unrelated to anything except flakes. That seems like a good reason to me.

• Flake is an extension to nix or installation would never be expected to be default, means it isn't an experimental feature but an experimental addon.

That doesn't make any sense when you look at the rest of the landscape. nix hash, nix profile, nix store, nix registry are all commands with their own sub-commands because they represent their own subset of functionality. Does that mean they are just add-ons?

Finally, I want to make one tongue-in-cheek remark as well: If you dislike typing nix flake so much, I have a hot tip for you:

alias nf='nix flake'

:wink:

[hugosenari]

and you didn't respond to a single one of my arguments.

Sorry, let me do it.

I think it's an oversimplification as well

If you have too much functionality on a single commands, you end up with ambiguities;

In "Additional context" of the issue I say "conflicts", you say "ambiguities". We are talking about the same problem.

The point is how to balance cognitive load with ambiguities/conflicts?

_{talking about ambiguities, we have it with flake subcommands, but is another issue.}

What would nix add add to what? What would nix install install where?

Nothing, we can't add/install unless you have a profile, and we have a profile subcommand.

What does nix update update?

We have a lock sub subcommand, update make more sense inside it.

Just like nix profile or nix store, nix flake is one layer of nix, and these layers are separate because you don't need to ever touch one to use the other.

Except that build, run, develop, aren't in one layer.

You still have the old-school bare expressions in nix files, and the "new way" of doing things needs to have some name to be able to differentiate it from the "old way" to communicate properly.

I think maybe some nix flake commands could be made general-purpose

Maybe we could follow your own suggestion, instead of tell user, you are using "new way" every time from now.

To visualize this, change "flake" by "new-way" in all current nix commands and arguments.

But nix flake lock (and almost every other nix flake command) only makes sense when applied to a flake.

I would go even further; flake commands are unrelated to anything except flakes. That seems like a good reason to me.

Flake is the "new way", not "the Flake", flakes commands makes sense for package (like build, run, develop).

to communicate properly. "Flakes" is such a name.

when you use them you have to know what a flake is. There's just no way around that IMO.

I liked the name, but do we need one, or we liked to have one?

Ie:

You have to know how to use it, not that it exists or that have a special name. ;-)

"How do I create a package with nix?"

nix init
# explain what goes in inputs and outputs

Instead of

nix flake init
# explain what is a flake, 
# expend time explaining that was the old way, but wasn't hermetic.
# and what goes in inputs and outputs

"How do I add dependencies?"

  # Open your packages.nix, in inputs add some nix URI
  inputs.dsf.url = "github:cruel-intentions/devshell-files";

Instead of

"Open your flake.nix, in inputs add some URI" "- Sorry, what is a flake?" "Explain what is a flake, expend time explaining that was the old way, but wasn't hermetic."

Could be default.nix instead of packages.nix, but we already use in the "old way", "old way" also not require it have a specific name.

I'm not arguing against the flake name, instead I'm saying that flake as an 'entity' only exists because we decided.

Additionally, flakes are not the only way to do package management or environment setup in Nix. You still have the old-school bare expressions in nix files

That doesn't make any sense when you look at the rest of the landscape.

We are in too early stage to deprecate the "old way", do we plan to do it someday? We will always advise two ways?

That's what I mean by "add-on". Add-on because the "standard" way would be always current one, the "new way" is some kind of special thing instead of "the way".

If you dislike typing

Fish auto complete solves this problem very well

The UX problem is, are we exposing some implementation and project rollout detail, only because we want?

Examples: We had "web 2.0" (with shine logo), it was the thing, but now days is web.

[hugosenari]

Visualization of "flake commands" (some is missing)

source

[infinisil]

Alternatively, make all commands that operate on flakes be nested under nix flake, or maybe even better, have a separate flake command.

[hugosenari]

@garbas in The NixOS hype and where to go from here, has similar insight: explain how not what. My idea is reduce the visibility of what.