Changes to GHC that will expose new packages

[Magnus Therning]

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)
2. Build and install *only* GHCi, using an already installed GHC and
   libraries

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://projects.haskell.org/pipermail/haskell-platform/attachments/20120323/f932cd5d/attachment-0001.pgp>