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

[Austin Seipp]

Hi Roman,

On Sun, Jun 9, 2013 at 1:44 AM, Roman Cheplyaka <roma at ro-che.info> wrote:
> I'm a strong -1 on this. As one example, we have forks of base and
> ghc-prim for Haskell suite:
>
>   https://github.com/haskell-suite/base
>   https://github.com/haskell-suite/ghc-prim
>
> which would be much more complicated if these were not independent
> repositories.

I hate being that person but, if the purpose of these forks is to work
around specific bugs in HSE and/or fix problems with name resolution
of GHC-specific terms, which sort of seems to be the case from the
log, I don't think hacking base & co. is a long term solution. It
could potentially need infinite ongoing maintenance. I went down this
road with LHC too.

And my gut feeling is that hacking ghc-prim out-of-band feels so
amazingly wrong I'm frankly not sure if "I need to fork it" can
actually warrant a huge amount of sympathy, to the point of keeping
the repository separate for that 1 fork in existence (granted,
ghc-prim is still pretty low traffic. But base is not.) If you DO need
help from GHC, is there really nothing we could easily and reasonably
do to further assist you? I think asking for specific, principled
solutions on our part is not out of the question here.

Are there any other forks of base people have for any particular
reason? What reasons are those?

> But more generally, I think there's still hope that the core packages
> will be made portable — I'm referring to Joachim Breitner's work on
> splitting the base.

To be clear, packages and their numbers aren't *really* the problem.
It's repositories. The numbers just make this slightly worse. Adding
packages and adding repositories both add overhead. Adding
repositories adds a significantly *larger* amount of complexity, all
things considered. The only honest, legitimate way to reduce that
complexity is to fold in repositories. But this means that we have to
give something up, too.

If base were to get split into 5 packages or 8 packages, that's
potentially fine by me, even welcomed. What I don't want is 5 more
repositories that are all intimately tied to GHC's build and features,
which a majority of GHC-specific work will be driven towards, and over
time that we then must manage and synchronize heavily. That's just a
massive amount of work. Just looking at Joachim's fork of base on
github, I already have some reservations about its current
implementation. Like, base-float still exports GHC-specific
namespaces. Every package still has a lot GHC specific code, as
opposed to some isolated substrate that we provide and base-* packages
interface with. So we're going to maintain all of that, it's the sad
truth. And if Joachim's patch were merged tomorrow somehow, I think
that frankly so much of it would still be under GHC control, my
argument would still stand. It would still be one repository. We would
still own it. It makes base more granular, but this has almost nothing
to do with our real problems.

Fixing all of that where we're not *actually* in control of it is a
ton of work. The current patches just don't solve that I think. And
this was last discussed in February? So what's the timeline here?
Clearly we're not even done with the API discussion at all. So, 6
months? A year? Who knows? "When it's done"? I'm not sure most of us
want to wait that long, especially considering the need to track down
bugs and have accurate historical logs is a fairly frequent
occurrence.

> Roman

-- 
Regards,
Austin - PGP: 4096R/0x91384671