Proposal: better library management ideas (was: how to checkout proper submodules)

Simon Peyton-Jones simonpj at
Mon Jun 10 09:42:19 CEST 2013

I forget who said it, but it's true that we have uncritically assumed that

*         One package = one repository
But I now realise that there's no need for that.   We could certainly have one repo with multiple packages.

What are the motivations for having a separate repository.  Are these two the main ones?

*         Sense of "ownership" by the maintainer. (My package isn't merely a barnacle on the side of GHC.)

*         Ability to release new versions un-synchronised with GHC releases

And neither really hold for the GHC-maintained packages.

One merit of splitting up 'base' will be that a chunk of it can go in the "independent" sector, leaving a smaller rump that is intimately coupled to GHC.  But we don't need to await that glorious day before getting on with the debate this thread is so constructively having.

Again: I am a non-expert. I will be happy to fall in with whatever you git experts decide, provided (a) you have some measure of agreement that it's step forward (b) you tell me clearly what my workflows should be.


From: ghc-devs-bounces at [mailto:ghc-devs-bounces at] On Behalf Of John Lato
Sent: 10 June 2013 01:00
To: Roman Cheplyaka
Cc: ghc-devs at
Subject: Re: Proposal: better library management ideas (was: how to checkout proper submodules)

On Mon, Jun 10, 2013 at 1:32 AM, Roman Cheplyaka <roma at<mailto:roma at>> wrote:

What I'm trying to say here is that there's hope for a portable base.
Maybe not in the form of split base - I don't know.
But it's the direction we should be moving anyways.

And usurping base by GHC is a move in the opposite direction.

Maybe that's a good thing?  The current situation doesn't really seem to be working.  Keeping base separate negatively impacts workflow of GHC devs (as evidenced by these threads), just to support something that other compilers don't use anyway.  Maybe it would be easier to fold base back into ghc and try again, perhaps after some code cleanup?  Having base in ghc may provide more motivation to separate it properly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list