Changing the -package dependency resolution algorithm

[Edward Z. Yang]

Good question.  I think package environments are the right answer here:
GHCi should come preloaded with some special global package environment.

Edward

Excerpts from John Lato's message of 2014-07-25 00:52:12 +0100:
> How would this work with ghci?  If I'm understanding correctly, the
> proposal means users could no longer do:
> 
>   $ ghci SomeFile.hs
> 
> and have it work without manually specifying all -package flags.  Did I
> miss something?
> 
> I think it would work in conjuction with the package environments stuff,
> provided that were available on all platforms ghc supports.
> 
> John L.
> 
> On Thu, Jul 24, 2014 at 11:12 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> 
> > Excerpts from Edward Z. Yang's message of 2014-07-24 15:57:05 +0100:
> > > - It assumes *-hide-all-packages* at the beginning.  This scheme
> > >   probably works less well without that: now we need some consistent
> > >   view of the database to start with.
> >
> > Actually, thinking about this, this dovetails nicely with the "package
> > environments" work the IHG is sponsoring.  The idea behind a package
> > environment is you specify some set of installed package IDs, which
> > serves as the visible slice of the package database which is used for
> > compilation.  Then, ghc called without any arguments is simply using
> > the *default* package environment.
> >
> > Furthermore, when users install packages, they may or may not decide
> > to add the package to their global environment, and they can be informed
> > if the package is inconsistent with a package that already is in their
> > environment (mismatched dependencies).  A user can also request to
> > upgrade a package in their environment, and Cabal could calculate how
> > all the other packages in the environment would need to be upgraded
> > in order to keep the environment consistent, and run this plan for the
> > user.
> >
> > Cheers,
> > Edward
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >