[Nix-dev] distutils2nix/python4nix

[Michael Raskin]

<87fwjn6xvn.fsf at write-only.cryp.to>
<87k48zdth3.fsf at eve.chaoflow.net>
<8739fn83pv.fsf at write-only.cryp.to>)
Mime-Version: 1.0
Content-type: text/plain; charset="UTF-8"

>Before we start writing cabal2nix, perl2nix, X2nix: How should the
>result look like?
>There are 20.000 ruby packages!
>And I personally don't like seeing more and more individual "let me
>update just this package and then that cause I need it right now and I
>don't know what this might break.." There is no choice unless we start
>supporting constraints.

I am afraid this would mean building a solid general-purpose 
data-grinding programming language into Nix. The idea to keep Nix small
seems to be still held, and it will not help us build a constraint 
solver.

We can - as usual - trade HDD space for sanity damage. That way every 
version of every package has its preference of versions of all other 
packages and we sometimes try to remove obsolete versions.

>In theory I've packaged all of those ruby packages. But do we really
>want to checkout such masses of .nix files to get only 10 packages?
>
>Or would it be much better to query PyPi package database, cpan, ..
>lazily (which would require changing nix?)

Or not Nix. If you have a way to programmatically generate all these 
expressions, it is a no-brainer to find/write a FUSE FS tht will simply
generate the file whenever it is needed. Default checkout will have some
packages voted essential, and everyone can mount overlay and pretend all
rubyforge is there.

The real problem with that solution would be deciding on policy of 
keeping checksums. Of course, I could keep checksums locally. That would
give me all local benefits of Nix (I can reproduce whatever I have ever
done - maybe I should copy checksum DB over to be sure, but that seems 
acceptable, if suboptimal), but denies global checksum synchronization.
Maybe we could have some online service to use for that database.

>For python there is another issue: You have to run the setup.py file in
>most cases to learn about package dependencies.
>
>I already have written kind python 2 nix and its good enough to install
>some packages on the fly but still needs much more love.

Looks like ASDF-Install tool for Lisp... 

Try installing, catch dependency problems, install dependencies,
retry installing.

Will work better for Python than for Common Lisp, because there
is only one setup.py per package.

>If you want to learn about this way (which perfectly work for all ruby
>versions) I'll point you to the code and explain how to use it.
>
>I personally believe that the final solution should take version
>constraints into account so that you can fail early.
>
>How should this all look in the future (there are vim, emacs, perl,
>ruby, python, eclipse, zsh, haxe, java, scala, ... ) packages to package.
>And eg for scala, java it almost impossible to keep up to date using the
>current manual way. It may be possible to tune the tools (sbt, maven,
>..) to use the nix store as cache at least..
>And I'm pretty sure that I've forgotten tons of package solutions (eg
>ocaml)