On 23 March 2012 12:19, Magnus Therning <mag...@therning.org> wrote: > On Fri, Mar 23, 2012 at 09:11:33AM -0700, David Terei wrote: >> On 23 March 2012 00:55, Magnus Therning <mag...@therning.org> wrote: >>> On Mar 23, 2012 7:25 AM, "David Terei" <davidte...@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. > It sounds like you might be moving in that direction. > > Tying ghci to a specific version of ghc ought to be possible to do > using dependencies in ghci's CABAL file, right? > >> Put this as option 5). Maybe it is the nicest / easiest solution >> until we have a proper way to handle internal packages. > > 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. Cheers, David > > /M > > -- > Magnus Therning OpenPGP: 0xAB4DFBA4 > email: mag...@therning.org jabber: mag...@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 _______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
