hacking cabal is too hard...

[Simon Marlow]

Duncan Coutts wrote:
> so what can we do about it?

BTW, thanks for all the cleanup you did over the weekend, looks great.

> Some barriers to entry:
> 
>      1. reporting bugs requires logging in, many people still miss
>         this. 
>      2. bug reports get ignored (which is disheartening to users)
>         because... 
>      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. 

The Trac configuration is set to auto CC this list with bug updates, but 
the mailing list config needs to be updated to allow them through.  Isaac 
is the only one with admin permissions on the list at the moment, should we 
add more people?  Volunteers?

>      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.

Again, this is a mailing-list setup issue.  cabal-devel should do the same 
as cvs-ghc, and moderate by default (but someone needs to do the moderation).

> 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.

...and I think a lot can be done to improve things incrementally.

There are abstractions that are not consistently used (eg. Program, but it 
sounds like you've improved things here), and missing abstractions 
(compiler-specific stuff is not sufficiently abstracted).  There are 
over-complex abstractions: e.g. hooks.  There are not-very abstractions: 
the "simple" build system is wired-in when it was originally intended to be 
layered on top of the basic infrastructure.  I'm not sure whether we should 
abandon this layering or try to do it properly.

All this has arisen because Cabal has been hacked on by a wide range of 
people, few of whom really took an interest in the design of the system as 
a whole.  Mostly we were trying to get the job done and make Cabal do what 
we needed, which to a large extent it does.

But this is fertile ground for hackers who enjoy cleaning things up and 
refactoring...

> 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
> release.
> 
> 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
> lists.
> 
> 
> 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.

thanks for bringing this up, it's definitely important.  Cabal is 
fundamental to the Haskell community now, we should look after it.

> 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.

Great!

Cheers,
	Simon