Enable GHC to use multiple instances of a package for compilation

Recently there have been a number of complaints about the Haskell infrastructure. By Haskell infrastructure i mean Hackage, Cabal, cabal-install, ghc-pkg, GHC. Most problems are attributed to cabal. I think the six most prominent ones are:

1. Destructive Updates: Installing a new package that causes another one to be rebuilt with different dependencies causes other packages to break. Solutions: Nix, cabal-dev, hsenv, virtualhenv, cabal-src.

2. No private dependencies: It is not possible for a package to depend on packages that depend on different versions of the same package, even if they don't expose anything from the different versions. Solutions: None that i know of.

3. No tracking of different ways a package is compiled: There is no way to see if the profiling version of a package was built or not. If it is missing cabal does not automatically build it. Solutions: None that i know of.

4. No private repos: It is difficult to build a package that depends on multiple packages that are not released on hackage. Solutions: cabal-meta.

5. Possibly untested packages on hackage: If someone uploads a new version of a package to hackage that makes breaking changes other packages might break if they use this new version. Solutions: cabal-nirvana, Haskell Platform, scoutess.

6. No build tool dependencies: Cabal does not automatically install build tools. Solutions: Well, there is another GSoC proposal

I want to attack number 1 and number 3.

The proposal

Basically I want to follow this plan. The next steps would be to make ghc-pkg able to keep track of multiple installed instances of a package and to have cabal-install put different instances of a package in different locations. I will try to find the signature of a package such that compilation is a pretty pure function of this signature. This will be hashed to uniquely identify a package.

ghc-pkg should maintain a working subset of the installed package instances as a reasonable default for "ghc --make" and "ghci". cabal-install should try to add a given package to that default. For more finegrained control people have to use a cabal file where you should be able to specify the exact instance a package depends on. Most of the time the required instances of a package should be figured out, possibly downloaded and built automatically.

The deliverable are branches of both cabal/cabal-install and GHC/ghc-pkg that are able to cope with multiple instances of a package. By midterm I should have a working prototype with a lot of bugs in it. By the end the bugs should be gone. I am not 100% sure that everything will work out well, but maybe some time later we should be able to merge the branches with the trunks.

About me

I am a fifth year student pursuing a MSc in Computervisualistik (Computer Science with a focus on Image Processing and Computer Graphics) at the University of Koblenz. I started learning Haskell four years ago. During my freshman year my Professor (Ralf Lämmel) teaching "Object Oriented Programming and Modelling" kept half jokingly preaching how much nicer Haskell is than Java. Now I use it for all my homework and toy projects.

I follow the haskell subreddit and I know that I can ask questions on StackOverflow and get a good and quick answer. I posted this to get an overview over the problem with cabal dependencies.

Since I'm currently on exchange in the US my semester ends in may and my german semester doesn't start until october, so I have a lot of time during the summer.