5 ms·

I'm a huge fan of the nix/guix projects (initially I was super excited to see a guix because I prefer scheme, but actually the Nix language is wonderful). I'm

by xiaomai 13y ago

I'm a huge fan of the nix/guix projects (initially I was super excited to see a guix because I prefer scheme, but actually the Nix language is wonderful). I'm really surprised the Nix package manager doesn't have a bigger following with Mac OS X people (it's a lot more capable than homebrew, and you get binary distribution for free). One problem I ran into as a ruby guy was building gems that needed to link against a C lib. Part of the beauty of the Nix approach is that it isolates everything. The "proper" solution I guess would be to package gems as Nix packages, but it seems like there probably should be some way to let a utility know the proper build flags for a given lib.

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 ago
  I'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.

by xiaomai 13y ago

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 ago
I'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.