On Tue, Apr 01, 2014 at 04:42:50PM +0000, Marc Weber wrote: > We should not be against a new option, we should think harder about > collaborating so that all targets will work - which one is the best fit > for use cases - future might tell.
Indeed. One of the things that seems (at least to me) wrong about the "let's download npmjs.org and convert everything to nix (ahead of time)" approach is that it still requires every developer who is not working on open source code to write nix expressions for their own project which likely duplicate the dependency infomation held in their project's language-specific format. So, developer is working on some ruby project, and like all good ruby devs, is using rvm and bundler, and will already have a gemfile and a gemfile.lock. Now they want to deploy this with nix. Even if there are nix expressions for all of rubygems.org in nix, the dev still has to convert their own gemfile.lock to nix. But let us not forget that these language-specific dependency files tend to be pretty declarative (or, to put it another way: this is hard enough already, so let's ignore all the systems that aren't declarative). Surely we can write some nix expressions or extensions that can take in these existing language-specific files and dynamically (and perhaps dynamically and recursively - maybe Shea Levy's work on recursive nix would help here) turn these requirments into satisfyable nix expressions. This way there would be no requirement for our dev to do anything, there would be no preprocessing, and all sorts of people might get their projects deployed and working on nix without even realising that it's happening. Matthew _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
