hacking cabal is too hard...
duncan.coutts at worc.ox.ac.uk
Sat Aug 4 10:09:25 EDT 2007
so what can we do about it?
Some barriers to entry:
1. reporting bugs requires logging in, many people still miss
2. bug reports get ignored (which is disheartening to users)
3. bug reports do not get reported to this list (like ghc ones get
reported to the ghc-bugs list). This also means we get no public
discussion going on most bugs, and the people who finally close
bugs get no public recognition.
4. there is no cabal hacking guide, a short guide to the source
code and style would help (eg explaining the main environments
functions operate in, ie BuildInfo, LocalBuildInfo). Simple
things like adding fields, commands or new flags.
5. it's not clear if it's possible to set up a local hackage
servers to help test & hack on the hackage web code.
6. darcs sending patches get rejected by default since the
cabal-devel list is subscriber only.
Probably more things.
People often complain that the internal Cabal code is hard to
understand, which is partly true though it's also related to point 4.
cabal-install should be easy to hack and there's not a lot to do to make
it really work well. We need to get someone to take an interest in it.
It should be a cool program to hack on because it should have a huge
number of users eventually. It's also important to get this going now
since the hackage web site is working better and better with more and
more packages and we want to bundle cabal-install with the upcoming ghc
Hacking infrastructure should be cool because so many people use it. We
need to lower the barriers to entry, get more people involved and reward
contributers with greater public recognition. We also need more people
to review patches. I'm not always especially quick at responding to the
few patches we do get contributed.
Then of course there's just doing a bit of evangelism to try and get
more contributers, eg blog postings or emails to the libraries and -cafe
Sorry for the rant, I've been hacking on cabal for a few days. I think
it must have made me bitter or tired or something.
Quick hacking report:
Thomas committed a series of 57 patches to add the new configurations
system. Since then Thomas and I have committed 54 patches and closed
several bug reports. We were trying some more radical refactorings, like
pulling the compiler support out into a proper Compiler abstraction
rather than each bit of code embedding per-compiler code locally. That
turned out to be a bit too difficult at the moment. I can give a more
detailed explanation if anyone else wants to have a go. Similarly we
were considering making some of the common environments into proper
monads, eg we have many environments with PackageDescription,
LocalBuildInfo and Verbosity. But this impacts on the hooks api, again.
More information about the cabal-devel