hacking cabal is too hard...
duncan.coutts at worc.ox.ac.uk
Mon Aug 6 11:42:20 EDT 2007
On Mon, 2007-08-06 at 10:16 +0100, Simon Marlow wrote:
> 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?
I'm a moderator too at the moment, however the list is subscriber only
so I only get notified about over-long posts etc. It was previously open
but moderated and we got a huge amount of spam.
> > 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.
Thomas has offered to write a HACKING file.
> > 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).
How does cvs-ghc deal with this? Does it go via a spam filter first
before the moderator? And can the mailman white-list people so on their
first post they can be cleared by the moderator to post from then on
(without the person having to subscribe)?
> > 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.
Yes, there's more work to do in improving the Program, PreProcessor and
> 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.
Cabal/Hackage is fantastically successful, despite the amount we grumble
about it's shortcomings.
> But this is fertile ground for hackers who enjoy cleaning things up and
Certainly. How to recruit such people...
I might try and do a 5-min status report at AngloHaskell.
"Cabal needs you" or something :-)
More information about the cabal-devel