[throwaway894345]

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

[microtonal]

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.

[mschwaig]

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.