3 ms·
Same here, Nix is exciting. The story with ruby still has some way to go before it is seamless. For each language they have an adapter that exports the languag
by zimbatm 13y ago
Same here, Nix is exciting. The story with ruby still has some way to go before it is seamless.
For each language they have an adapter that exports the language-specific package manager to nix expressions. cabal, perl, python and ruby are all supported (maybe more). In the case of ruby there is `nix` ruby gem that you can use to generate a .nix expression. Ideally you could amend it to say that nokogiri depends on libxml2 and such. Then your project could have a deps.nix file that you can install. `nix-env -f deps.nix -i`
I'm also exploring different ways to work with my projects. For example creating a custom profile per project that's derived from a project-specific derivation.
- sparkie 13y agoI'm not particularly a fan of the idea of static converters to nix expressions, ala cabal2nix. They require someone to run them in the first place, so you don't pick up updates to packages dynamically. I'd rather we collectively agree on a protocol for installing, updating, querying packages etc, such that each language-specific package manager can talk to others through a daemon and install foreign packages that are required for the projects. It would require a fair amount of work to update each package manager to talk it (optionally), and agree on the semantics and policies of the protocol, but I think the benefits could be huge. Using Nix/Guix as the basis for such protocol would probably be ideal due to the immutable nature of packages and ability to install side-by-side versions, and that you can specify an identity of a dependency, rather than rely on fuzzy matching of name and version.