Nix doesn't provide the source package metadata and publishing infrastucture that CPAN/rubygems/pypi provide. In fact nixpkgs is a consumer of those infrastructures.
On the client side, nix expressions' dependency resolution is name-based. Meaning you can say: my program depends on "ruby" and the definition of "ruby" gives you the version of ruby. As program dependencies tend to evolve quite a bit it would be a chore to update all the dependencies manually, we are used to having a sat solver to do the work for us.
Both things could be bolted onto Nix I think. You just need that publishing infrastructure (github is an existing one for a start) and a dependency solver that generates nix expressions.
> dependency solver that generates nix expressions
I have some code that uses Bundler to convert its Gemfile.lock (resolved dependencies) into a set of nix expressions. I think it's a nice way to go.
(Though Bundler is aimed at end users, which for my use case means an annoyingly large amount of functionality and no stable api; e.g. it insists on installing gems as part of the dependency resolution process.)
Last I checked, Nix has no way to publish just a small nix expression for one project. You'd really need to include the entire stack of nix expressions for all your dependencies, all the way down to gcc (which is exactly what nixpkgs is), or somehow declare "depends on http://nixpkgs/2014-07-24.tar.xz".
That's pretty cool. I was thinking of bundling a default.nix in the root of my projects with maybe a recipes/ folder for things like ruby, libxml2, ...
It's definitely possible to do that and even link to nixpkgs but then your projects dependencies might break each time you updated nixpkgs. I don't know of a nice way to solve that.
My sample looked something like that:
let
pkgs = import <nixpkgs> {};
stdenv = pkgs.stdenv;
in
stdenv.mkDerivation {
name = "my_project";
src = ./.;
...
There's also a deps.mix for just the dependencies. It's on an internal project so I can't really divulge the details but email me if you want to talk more about it.
On the client side, nix expressions' dependency resolution is name-based. Meaning you can say: my program depends on "ruby" and the definition of "ruby" gives you the version of ruby. As program dependencies tend to evolve quite a bit it would be a chore to update all the dependencies manually, we are used to having a sat solver to do the work for us.
Both things could be bolted onto Nix I think. You just need that publishing infrastructure (github is an existing one for a start) and a dependency solver that generates nix expressions.