Hi Marc.
Here's a start.
Plan for Haskell packages in NixOS:
(1) Haskell packages require a package database at build time.
This can be solved by using setupHook.
Option A:
Just build a GHC_PACKAGE_PATH.
Pro: Very simple to do in setupHook.
Con: Requires a patched Cabal.
Option B:
Build a local package database.
Pro: Seems relatively stable from the GHC side.
Con: Slightly more work for the setupHook.
I'm in favour of option B. I think Cabal is a fast-moving
target that often has changed its internal interface
completely in the past. Since both options have been
implemented already, it's not more work to go with B now.
(2) Cabal packages should be built generically.
There should be a builder (much like stdenv.mkDerivation)
that can build Cabal-based packages easily. In principle,
not much more than package name and version and dependencies
should be required for each package.
Two such builders exist:
development/libraries/haskell/cabal/cabal.nix
(written by kosmikus)
top-level/all-packages.nix, ghcCabalDerivation
(written by MarcWeber)
Both are being used. We have to agree on a common set of
features and merge.
Goals:
- We need a good location for the result. Both the current
locations are suboptimal. Library code does not belong in
all-packages.nix, but neither is it clear that the Cabal
builder should be in the location where one would expect
the Cabal package.
- The Cabal builder must work successfully with (1).
Currently, kosmikus' builder uses scheme 1B, whereas
MarcWeber's builder apparently can use both 1A and 1B.
(3) Haskell libraries should be available for the user.
A user must be able to use Haskell libraries installed to
the user profile.
Option A:
Adapt the builder of the user environment. That builder
currently just symlinks in all files of all installed packages,
but it could easily perform extra work, such as generating
a package database on the fly. Ideally, this would not be
hardcoded in the builder, but instead the builder would read
a specific file from nix-support that ghc installs there, and
that file would hook into the builder and generate the database.
Pro: Works nicely with the current UI. The user can just
"nix-env -i" a Haskell library and will have it available.
Con: It might be tricky to maintain internal dependencies
between database entries properly, but with
propagated-user-env-packages it should be possible.
Option B:
Have a wrapper function. The function takes a ghc and several
packages built for that ghc and creates a database plus a shell
wrapper that invokes ghc with the database. The result can then
be installed to the user profile.
Pro: Possibly more general. One can create arbitrarily many
wrappers, possibly even multiple wrapper per profile.
Con: Quite tricky from the UI side. The packages would probably
be determined via user configuration. This requires users
to find out about it, and requires them to know which
packages can sensibly be put there.
Option C:
Require from the user to register packages.
Pro: Very easy to implement.
Con: Inconvenient. It's easy to get package databases that
are inconsistent.
I am currently in favour of option A. It can be implemented
without much effort, and seems easiest to use for now. It's
certainly not a fault to support some wrapper function as
well, and we might switch to it at a later point when the UI
side has changed. C is clearly the worst option, but it's
used at the moment by kosmikus' Haskell packages.
(4) Use HackageDB to generate Nix expressions automatically.
Requires an external tool. Generated expressions should use
the Cabal builder (2). Some additional information is probably
required for packages, but that should be specified as an
input to the external tool, so that we can easily call the
tool at any time to regenerate package descriptions from
current HackageDB. This also allows use to exclude packages
that do not work.
(5) Separate GHC from its core libraries.
This has already been done by MarcWeber, and is ultimately
advisable because it allows users to install GHC with fewer
packages, and also to upgrade core packages. Perhaps most
importantly, it allows to decouple Cabal from GHC. Often
packages need a newer Cabal version than the one included with
GHC.
I think these five issues are the most important. Most of it has
already been done in one form or another by MarcWeber, amiddelk,
or me. We need to clean up and devise something well-documented
from it.
The issues can be addressed in order, although we should make all
the decisions in advance.
The question is how we get there: we currently have two Haskell
systems in nixpkgs in parallel. We can
- add a third one,
- work in a branch,
- convert one of the two existing ones.
I'm opposed to the conversion approach, because I think it leads
to worse code.
Comments?
Cheers,
Andres
_______________________________________________
nix-dev mailing list
[email protected]
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
