Hacker News Reader

Comment by soraminazuki | Hacker News Reader

If Nix was about replacing apt's CLI syntax, then sure. But its promises are more than that.

Is there any data on how many people care about said promises as opposed to care about not having an actively hostile and prickly interface? Because I enjoyed tinkering with this kind of thing in my 20s, but in my 40s I just want something that I can use without having to memorize a ton of arcania, and that lets me solve my problem and get back to my actual goals.

I never wake up saying "today I want to install a package on my computer and revel in my extreme knowledge of how my package manager works". I wake up with plans, and installing a package might be necessary to achieve them.

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?`

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.

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.

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

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.

It's ok for you to not like it or not get it. Other people have different needs than you have.

> Is there any data on how many people care about said promises as opposed to care about not having an actively hostile and prickly interface?

git being popular

In practice, you will either write `nix shell nixpkgs#package` for one-off packages, or will add one single line into your configuration.nix/home-env config file and issue a rebuild.

I’m near 40 and I can very much relate.

However: I believe that what the Nix crowd is doing is exploring new ways of packaging and deploying software.

It’s quite different from eg. APT and Yum. The upside is quite big. But one cannot expect them to get every little detail right on the first try. I think it’s impossible to do something like this without experimenting. Or doing a series of Versuchs if you will.

Therefore I do not view Nix and NixOS as a polished consumer-grade product. I would not use it in prod as of now. IMHO it’s too early for that.

I won’t even try it on my laptop. I already have homebrew, which is much simpler and works well for my purpouses.

I still find Nix very interesting. I do believe it has potential.

But what will it lead to? Will Nix be able to deliver on it’s grand promises?

Maybe! Or maybe not. Time will tell. In the meantime I’m here on the sidelines, watching with great curiosity.

Nix itself might never become a big player. But even if it doesn’t, I’m certain that many great ideas and practices will evolve from the Nix Versuchs.

PS. A friend of mine pointed out that Nix has been around since 2003. Ha. TIL!

At least for me the thing is I never "just" want to install a package (for myself).

If its a personal PC I probably also want the package if I ever were to reinstall the PC. => Use NixOS and add it to the configuration.

If its for work I probably want my colleagues to have the package as well => nix-shell.

Once I started using Nix just quickly installing a package felt really hacky to me, just like a dirty workaround.

I just hate when some project's README.md says: "Yeah, just do apt-get install <long list of packages> and you are good to go".

The chance that this works successfully is about 0.

EDIT: typo

Why can't it promise more than that without a terrible CLI? Seems like a poor excuse.

I think it's good to consider ways in which Nix's UX could be improved.

But I'd draw an analogy to vim or emacs. These have steep difficulty curves to them, but provide a power-user experience. Roughly, Nix is to apt-get what vim is to notepad. -- It'd be weird to try vim but live in insert mode the whole time.

It's not a matter of "no-the-ux-doesn't-suck", but more "if you can get past the rough edges, the things which Nix allows are wonderful".

Speaking of vim vs emacs, how does the nix command line interface compare to GNU Guix?

Guix greatly simplifies things. Like others said for Nix, I really would recommend managing things declaratively in your system config and a manifest file, but the basic cli isn't bad.

guix install ranger

guix remove ranger

guix pull

guix upgrade

guix search ranger

These basics just work how you'd expect last I checked. There is some `guix shell` stuff as well, but I don't use it, so won't be able to say much about it.

See the refcard for an overview on the Guix CLI: https://guix.gnu.org/guix-refcard.pdf

What is terrible about explicitly specifying the source of the package definition? Seems like a dramatic conclusion to make based on a minor detail of the command line syntax.

Reply on news.ycombinator.com