[Nix-dev] Proper way of adding custom nix expressions
Marc Weber
marco-oweber at gmx.de
Thu Nov 1 02:30:18 CET 2012
Hi Daniel,
let's talk about the problems & concerns.
Right now its maintained by me only.
the solver is
- a proof of a concept, but works
- written in Nix (which is not the right language, and its little bit
slow, but bearable, and hard to read and understand what is going on
exactly)
- is using "brute force" (which requires limiting the input, thus the
pool of available packages)
- some more care should be taken about which haskell platform should
be used. Right now the latest packages on hackage and some manually
selected older packages to fit dependencies of Haskell libraries I
cared about in the past is used currently.
- some less important new cabal features such as "tests: .." are not
supported yet.
- Peter & Andres have proofen that the "manual" way works reasonable
well for most packages - something I would not have believed in.
Probably this is due to the fact that most other distributions can't
be much smarter so some pressure is there to keep packages working
the way it is - thus by using one platform and often the same set of
verions. At least that's my interpretation.
Still very often it "just works" for me - morevoer it also automatically
generates tag files which is very valuable to me.
In the past it would have been wrong to make it "the standard" - due to
many updates and continuous progress. There are more than 5000 packages on
hackage - and only 100 are used very often. Thus it may even be
considered bloat.
For those reasons - even if it should become a second alternative
standard I'd keep everything little bit separate. The haskell
derivations from nixpkgs are reused anyway. My fork is only required
because I add information about the library versions shipping with ghc.
The same problem exist for ruby,perl,python,... In the Ruby case there
are about 50.000 packages or such. I've done something similar for
rubyforge. (and scala,java, ... there are much more challanges)
Thus before you make such request - get started with hack-nix, then
judge with confidence.
> moving projects, manually creating nix expressions is an extra effort that
> I would like to be able to avoid.
The minimal effort which would be required to make hack-nix more
standard would be merging the overlay patch and the additional package
information which libraries are shipping which each ghc version.
If you need help you can always ping me on irc or by mail.
Marc Weber
More information about the nix-dev
mailing list