Using Nix to write packages sucks, but I think the parent is talking about using it as a package manager (I.e., to install packages that others have written), which is usually a pretty good experience.
Could you explain a bit more what you mean? I had prior experience making Debian packages (on Debian and Ubuntu), Arch packages, and a bit of Homebrew on macOS. When I started writing Nix derivations two years ago, I found that it much easier than making Debian packages. Arch packages were easier than both, because the build scripts are just shell scripts, but I found it easier to make correct packages with Nix.
If I have an app and I want to build it with Nix, it’s typically a lot more work than using my language’s native packaging tooling even if Nix just calls that tooling under the hood. Nix gives me things that my language’s package tooling doesn’t (such as treating my application as part of a larger heterogeneous assembly), but very often that tradeoff isn’t worthwhile (and much to my chagrin because it would be very nice to use a single build tool to manage everything in my project).
Thanks for clarifying. I thought that you were referring to traditional package managers, not language package managers (such as cargo or npm).
I have most experience with Rust/cargo and packaging Rust applications is really easy with buildRustPackage. As a bonus, you can also easily pull in necessary native libraries.
On the other hand, things like Python packages are pretty tricky.
One of the problems is that the Python ecosystem does not have a strong tradition of semantic versioning. For that reason, a lot of Python packages have (perhaps overly) strict bounds. That works fine for something like pip, which can pick any version of a Python package and can typically find a way to resolve all dependencies. But it's harder with Nix, because nixpkgs only ships one version of Python packages (for good reasons).
Another issue with Python packages that I encountered several times is that some Python packages directly modify their own paths (e.g. until recently Huggingface datasets), which breaks with the read-only Nix store.
For using Python packages that are avialable via pip I have been quite happy with [mach-nix](https://github.com/DavHau/mach-nix), which can pull prebuilt python wheels(?) from pip directly. You can also configure it to obtain those packages in other ways, like from source via pip or from nixpkgs. You can also feed it Python packages you have in source code form locally.
I can imagine sitting down and migrating a lot of complex packages to Nix is probably quite a tall order right now. Partially because I think a switch like that is always painful, but also because of the open issues, bugs, yet unanswered questions and usability issues that do exist.
I think it depends on if your use case allows for a gradual transition and on your tolerance for migration pain wether or not Nix is worth the trouble right now.
Even if packaging is more difficult with Nix, I appreciate that packages do end up containing a much more precise and flexible description of what they depend on.
Even many toy applications is painful for one reason or another. For example, even a Python toy app is likely to use a C-extension dependency that hasn’t been packaged in Nix yet, and since C’s ecosystem is a trash fire, you’ll have to figure out how to package it and it’s transitive dependencies in Nix. You have different problems in Go, where you need to provide the hash for the vendor derivation, but the only documented way to get that hash is to run a tool that only works on Linux (and I’m on MacOS). And in whatever case, the documentation for the Nix ecosystem is sorely lacking, so odds are you will have to reverse l-engineer other similar package definitions in nixpkgs to figure out how to make your own package.
Note that these issues aren’t insurmountable, but it doesn’t seem like the Nix community cares very much about them (and of course it’s open source software so there is no obligation for them to care, etc but that doesn’t magically make it a good tool for these use cases either).
Could you explain a bit more what you mean? I had prior experience making Debian packages (on Debian and Ubuntu), Arch packages, and a bit of Homebrew on macOS. When I started writing Nix derivations two years ago, I found that it much easier than making Debian packages. Arch packages were easier than both, because the build scripts are just shell scripts, but I found it easier to make correct packages with Nix.