[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