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

[Roman Cheplyaka]

My motivation for having a separate repository is that I can check it
out and work on it without having to check out the whole GHC.

At the moment base and ghc-prim are used by the name-resolving compiler
http://haskell-suite.github.io/haskell-names/

Roman

* Simon Peyton-Jones <simonpj at microsoft.com> [2013-06-10 07:42:19+0000]
> 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.
> 
> Simon
> 
> From: ghc-devs-bounces at haskell.org [mailto:ghc-devs-bounces at haskell.org] On Behalf Of John Lato
> Sent: 10 June 2013 01:00
> To: Roman Cheplyaka
> Cc: ghc-devs at haskell.org
> 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 ro-che.info<mailto:roma at ro-che.info>> 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.