[mschwaig]

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.

[throwaway894345]

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).