Changes to GHC that will expose new packages

[David Terei]

On 23 March 2012 15:12, Magnus Therning <magnus at therning.org> wrote:
> On Fri, Mar 23, 2012 at 02:08:41PM -0700, David Terei wrote:
>> On 23 March 2012 12:19, Magnus Therning <magnus at therning.org> wrote:
>>> On Fri, Mar 23, 2012 at 09:11:33AM -0700, David Terei wrote:
>>>> On 23 March 2012 00:55, Magnus Therning <magnus at therning.org> wrote:
>>>>> On Mar 23, 2012 7:25 AM, "David Terei" <davidterei at gmail.com> wrote:
>>>>>>
>>>>>> So do we have any proposal for a way forward here? seems the options now
>>>>>> are:
>>>>>>
>>>>>> 1) Include mtl, haskeline, terminfo, utf8-string. Mark as hidden all
>>>>>> except mtl.
>>>>>>
>>>>>> 2) As above but rename all except mtl to be ghc-*
>>>>>>
>>>>>> 3) Discuss including packages that provide functionality equivalent to
>>>>>> above packages in haskell platform, rework ghc code to depend on those
>>>>>> instead, include all packages and expose them.
>>>>>>
>>>>>> 4) Fix cabal / ghc to allow ghc to depend on packages and have them
>>>>>> remain truly internal
>>>>>>
>>>>>> I'd be happy with any of the first 3 and particularly the first 2 as
>>>>>> it minimizes the work i need to do. Long term 4 seems to be the right
>>>>>> approach.
>>>>>
>>>>> Just to make sure it's explicit. Does this mean that breaking out
>>>>> GHCi to a seperate package isn't an option?
>>>>>
>>>>> If so, would it be possible to hear why?
>>>>
>>>> That is what I'm doing. In the GHC source tree GHCi is already its
>>>> own package but it only includes executables, so its package
>>>> dependencies aren't an issue. I'm changing it to also expose a
>>>> library as I want to expose an API.
>>>>
>>>> Now we could technically make this changed package a *new* package
>>>> separate from the rest of GHC. However this would involve simply
>>>> copying the code. So we would have an ongoing maintenance issue of
>>>> keeping the code bases in sync. So yes, this is an option but an
>>>> ugly one from a software engineering point of view. There are ways
>>>> we could do build script hackery to mean we wouldn't need to copy
>>>> the code I guess. The GHCi package will be very specifically tied to
>>>> a version of GHC though.
>>>
>>> First of all I'm not suggesting that you make any changes to how
>>> ghc/ghci is *developed*, you keep doing that in whatever manner you
>>> see fit.  What I am suggesting is that the distribution of the
>>> source packages is separated, i.e. that ghc sources come in one
>>> tar-ball and ghci sources in another.
>>>
>>> The ideal situation, for me as a distro packager, would be if I could
>>> do the following:
>>>
>>> 1. Download, build and install ghc (without ghci)
>>> 2. Download (from Hackage), build and install all deps for ghci
>>> 3. Download (from Hackage), build and install ghci
>>
>> This is an orthogonal issue. I'm saying I want to increase the deps
>> needed for ghci. Now making ghci and ghc separate components from a
>> package managers point of view doesn't change this in a meaningful
>> way. Sure you could just not grab the ghci component and you wouldn't
>> be hit by the new deps, but the Haskell Platform I imagine will always
>> want to bundle up both ghc and ghci. They are aiming for ease of use
>> and installation after all. So the Haskell Platform still ends up
>> pulling in the extra deps, which is the issue.
>
> I'm sorry, but I don't see the orthogonality.
>
> I see no difference between HP and other packagers; we all are in the
> business of providing GHC and a choice of tools and libraries.  To be
> a bit blunt: HP is a package of Haskell for platforms with poor
> package managers (read Windows).  I don't think any packager would
> ever consider *not* including GHCi.  Adding specific versions of
> Haskell packages to GHC means that *all* packagers are tied to those
> versions.
>
> I may be wrong, but I don't think the following is possible with the
> GHC sources today:
>
> 1. Build and install *only* the compiler and its libraries (i.e. *not*
>   including GHCi)

So maybe I'm missing something here as I'm not familiar with the
issues involved with packaging GHC. But don't you need to have GHC
when installed include a bunch of libraries that it depends on like
ByteString, Hoopl... ect? Separating out GHCi won't change that
situation.

> 2. Build and install *only* GHCi, using an already installed GHC and
>   libraries

OK sure. Now any user (which is all users basically) that want to use
GHCi will end up with a specific version of Haskeline, utf8-strings,
terminfo and mtl on their system. Given the end result for users is
the same and I thought that was the point here this is why I think
what you are proposing is orthogonal.

I'm most likely at this stage just going to create a copy of sorts of
the code I need and put it in a package on hackage with very specific
ghc version dependency.

>
> That would be the kind of separation I'm arguing for.  Separate source
> distribution would be one way to ensure that.  A changed build system
> would be another way.  Once that is possible GHC can include any
> libraries, because as a packager I can choose not to use them (though
> in some cases patching may be necessary).
>
>>> If you do go this way, why would you ever want to go in the
>>> direction of using internal packages?
>>
>> In the situation we have the possibility of splitting out the code
>> from the main ghc code base. However, what happens when GHC proper
>> wants to depend on some new packages? Every time the GHC developers
>> want to make this decision we can't make it in isolation as it means
>> the Haskell Platform is affected.
>>
>> Basically, GHC tried to get out of the packaging game but hasn't
>> actually managed to do that. Allowing GHC to decide what packages to
>> use and what version in isolation is a worthy goal that hasn't been
>> realized.
>
> True, but wouldn't it then be better to make the build system more
> modular?
>
> /M
>
> --
> Magnus Therning                      OpenPGP: 0xAB4DFBA4
> email: magnus at therning.org   jabber: magnus at therning.org
> twitter: magthe               http://therning.org/magnus
>
> I invented the term Object-Oriented, and I can tell you I did not have
> C++ in mind.
>     -- Alan Kay