3 ms·
What I wind up doing while developing is just creating a nix-shell with my native dependencies, and using pip/cargo/whatever inside that. It's not the "proper"
by vertex-four 9y ago
What I wind up doing while developing is just creating a nix-shell with my native dependencies, and using pip/cargo/whatever inside that. It's not the "proper" way of doing things - you wouldn't want to install a tool long-term that way - but it's useful for one-off things or while you're playing around.
I've used npm2nix and cargo2nix a couple of times with success - they generate package sets from the relevant sources.
- hollerith 9y ago>you wouldn't want to install a tool long-term that way I'm curious why not. Aren't pip/cargo/whatever suitable for long-term use? Consequently, couldn't nix's upgrading routines be modified to call out to pip/cargo/whatever to upgrade things best upgraded by pip/cargo/whatever? I guess what I want to know is whether the architecture or the philosophy of nix interferes with nix's being modified in the way I just described. (Maybe it is just that nobody's gotten around to doing the implementation work.)
- vertex-four 9y ago> Consequently, couldn't nix's upgrading routines be modified to call out to pip/cargo/whatever to upgrade things best upgraded by pip/cargo/whatever? No. pip/cargo/etc are nondeterministic. Nix packages should not be. Where they are, things often break in bizarre ways. In order to access the Internet, a Nix package must declare the hash of its output - given that pip can produce different output from run to run (it contains a constraint solver which depends on the versions available in the external package repository) this is impossible.