Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

Well, there is a model change as well, traditional package manager doesn’t make as much sense for Nix.


sort by: page size:

Specifically, it uses Nix as the underlying system, but implements a new syntax and maintains a separate package tree written in this new syntax. I'm not entirely certain why.

Redesign of nix command line is a good thing. Nix should be more intuitive.

I totally agree that nix is the future of package management.


We've seen the opposite. New package managers are built with a much better understanding of the problem space because of Nix and sometimes explicitly taking ideas and concepts. This results in those new systems being far more compatible and easily integrated with Nix itself. Consider the iteration towards better and better locking in python + Node. Consider Rust/Cargo.

There has also been sharing of ideas and collaboration between things us and bazel/buck/spack/etc. I think it is clear that we are all moving towards a similar end state, that often looks very much like Nix, or a re-invention of it.

For things like OCI, Nix predates it, but we should start to re-use the standard. The Tvix group is exploring this and I'd suspect our sandboxing will be OCI at some point. For outputs; we make it easy to convert a Nix package into an equivalent container. Things like flatpack,AppImage,Snap should also be easy for people to output (i'm trying to collect these "transformers"/"bundlers" here: https://github.com/NixOS/bundlers).


Nix isn't designed as an application. It's designed as a system package manager.

Okay I read the full readme and things have changed since last time I read about this. Now this seems to bring actual neat features to package management vs. what exists now. I wonder how they did truly relocatable packages… probably like Nix did it, I suppose? If this really turns out to be an easier-than-Nix Nix, it could be great!

There’s still the NFT/crypto side I do not like, but the product looks somewhat fair compared to what this was a few months back.


Wouldn't it still have been less effort to port Nix to Windows, than to write an entirely new package manager and then port it to every OS?

First yum - "a package manager written in Python" and now Nix - "a purely functional package manager". Well, I for one do not care the least which language or paradigm my package manager is using. What I do care about is compatibility, reliability, speed and correctness. How is Nix improving the situation for the user?

People might just not like nix for a number of legitimate reasons and they might to take an attempt at a new package manager with better UX. It's fine to make a new piece of software, even if 100 tools exist already. Package management is definitely far for a solved problem, and I personally don't think than nix is "it".

You're stating a lot of interesting opinions, but I do not see any arguments to help describe why you feel that way. How exactly is Nix monolithic or proprietary? And what is complicated about it? It seems pretty simple to me, if not at odds with how other package managers do things. It's one of the few package managers that can successfully work across multiple Linux distributions, some BSD systems, MacOS, and even Windows for some software. In my opinion it's the least proprietary or monolithic package managers around, the other being Guix which follows the same principles.

But I think the biggest issue is in your last paragraph where you don't describe why or how the solution needs to happen in the software itself rather than at a higher level.


In theory nix can solve that, in practice is more ergonomic to leverage a language's native package manager even in nix.

Nix is building a package manager AND a programming language. Guix is building a package manager only. It's a resourcing thing.

My gripe is that it doesn’t solve the problem, just pushes it a layer away.

Nix is the first package manager that actually gives a proper solution, and it is just much much better and has no space overhead either.


Same here. To be fair the Nix package manager has a name that is actively harming its growth since most people think *nix as in unix when you say nix.

About to write "they aren't the same thing" as I remember Nix aliases the language, package manager and OS.

Nice.

Half-OT: How is the new CLI coming along? AFAIK there was an effort to make Nix usage a bit more like known from other package managers.


I can only guess here. But remember that software package management was a pain too and it took someone to do a Ph.D. on the topic to give us NiX (and it still isn't perfect).

Reading your linked post, it seems you are wrestling with how Nix works.

Nix is hard to learn. The concepts used are almost the same, but different. That's because it's solving slightly different problems than package managers currently do.

As the overriding example shows, the versions are pinned by hash and are stored in a file. What about it is not maintainable or scalable?


I get what you're saying, but I don't think it violates the Unix philosophy in that way, at least not any more than any other package manager like apt or dnf does.

Nix as a package manager is made up of multiple tools that interact, such as nix-env, nix-store, nix-shell, etc.

NixOS additionally has nixos-rebuild and other commands that are layered on top of those core Nix commands.


Your criticism is valid, but only temporarily. Lack of the packages in those 2 (in particularly Nix) is because the distro is pretty new in comparison and the community is not nearly as big as the ones of major distros.

On the other end, Nix's way is obviously a future in terms of package-management systems in comparison to the package-managers of the past - to a degree that I haven't seen anyone who read the docs ([1]) saying anything negative about the core ideas - I'd imagine that most people get blown away and become converts.

[1] https://nixos.org/nixos/packages.html

next

Legal | privacy