Changes to GHC that will expose new packages

[Magnus Therning]

On Fri, Mar 23, 2012 at 03:54:02PM -0700, David Terei wrote:
> 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.

Completely true, but what separating out GHCi in the way I propose
*will* do is allow it to be changed separately of GHC.  For packagers
the meaning of "change" could be such things as adding patches
relaxing constraints to allow upgrades of GHCi's dependencies.  If the
build system of GHC tightly bundles GCH, GHCi and supporting libraries
such change is *considerably* more work.  Basically, without it
packagers would likely only upgrade those supporting libraries when
GHC ships with upgraded versions.

>> 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 suspect that you overlook the possibility of packagers patching
libraries.

> 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 sounds very good.

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: magnus at therning.org   jabber: magnus at therning.org
twitter: magthe               http://therning.org/magnus


Perl is another example of filling a tiny, short-term need, and then
being a real problem in the longer term.
     -- 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/20120324/b39baaea/attachment.pgp>