Nix: An idea whose time has come

Re:Nix: An idea whose time has come by soraminazuki on Saturday February 19, 2022 @01:51AM (#30394937)

To be clear, Nix's CLI syntax is what it is because of the following requirements:

* Provide the ability to create a new package by extending an existing package definition programatically

* Provide the ability to have multiple variations of similar packages

To satisfy those requirements, you need a way to uniquely specify packages by its precise location of its definition. It does not interact well with apt's model of having a central package repository assign names for every known package.

> "today I want to install a package on my computer and revel in my extreme knowledge of how my package manager works"

Was this straw man mockery really necessary?`

[ Parent | on HN ]

Re:Nix: An idea whose time has come by brongondwana on Saturday February 19, 2022 @04:59AM (#30395832)

Not strictly necessary, but neither is the dismissal of serious usability issues as "well actually, it's this way because of reasons" which basically boil down to "not designed with the kind of use-cases in mind that many users here are saying cause them pain". The idea that you can't remove a package by the same name you added it by is just obnoxious.

Sure there are reasons for it, but the reasons boil down to "screw you users" if you're just trying to use it. And a project which is actively hostile to usability feedback doesn't fill me with excitement to start depending on it.

`nix install foobar`: There are N versions of foobar. Choose one of:

* nix install foobar.gnu

* nix install foobar.lfs

* nix install foobar.experimental20220104

(pre-formatted for copy-paste)

`nix remove foobar`

You have two versions of foobar installed. Choose one of:

* nix remove foobar.gnu

* nix remove foobar.experimental20220104

[ Parent | on HN ]

Re:Nix: An idea whose time has come by soraminazuki on Saturday February 19, 2022 @07:10AM (#30396521)

If you pick on every little detail that differs from an existing tool, call it a serious usability issue, and accuse others of “actively being hostile,” “screwing users,” and “being obnoxious” for the sake of it, that’s the end of any reasonable discussion.

Different tools have different use cases, design goals, and priorities in mind. That is in no way a justification for name calling and mockery.

[ Parent | on HN ]

Re:Nix: An idea whose time has come by atoav on Saturday February 19, 2022 @04:23AM (#30395656)

How about just using the default source that users would like to use 90% of the time and then provide an option to override this default?

Nix is a great system, which is why it would be a waste to not invest some thought in it's CLI ergonomics.

[ Parent | on HN ]

Re:Nix: An idea whose time has come by soraminazuki on Saturday February 19, 2022 @04:53AM (#30395795)

Nix devs seem focused on improving the ergonomics of the new command line, but it’d probably take time to flesh out the details. In the meantime, I think specifying the package source is a reasonable tradeoff given the features it enables.

I also suspect that keeping the package specification the same between installation and uninstallation time is harder than it might look, though. By its nature, Nix identifies packages by the contents of their definition. “nixpkgs#ripgrep” is merely a pointer to the current ripgrep package definition in the Nixpkgs repository. Therefore, “nixpkgs#ripgrep” will likely not point to the same package at the time of uninstallation.

[ Parent | on HN ]