What's next?

Yuri de Wit ydewit at gmail.com
Fri Sep 6 00:52:23 CEST 2013


fyi, below you can find an expanded list of related links.

I do appreciate the new sandboxing feature in 1.18 and I think it is a
great feature, but it is not addressing the core issue here: adding support
for multiple instances of the same version. It also seems to me that
supporting this would be a relatively low hanging fruit that could have a
big impact to the whole ecosystem once addressed. So why not address it? I
don't have enough exposure to Ghc or Cabal to make a difference here, now
(what is needed is an elaboration of the issues together with a minimal
solution), but I would be willing to participate in a supporting role
(testing, reviewing, and minor bug fixes).


GSoC 2012 - Enable GHC to use multiple instances of a package for
compilation - Philipp Schuster
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/phischu/1
http://www.google-melange.com/gsoc/project/google/gsoc2012/phischu/19001
https://github.com/phischu/cabal

GHC Commentary
http://ghc.haskell.org/trac/ghc/wiki/Commentary/Packages/MultiInstances
http://ghc.haskell.org/trac/ghc/wiki/Commentary/Packages
http://ghc.haskell.org/trac/ghc/wiki/Commentary/GSoCMultipleInstances

Mailing list
http://comments.gmane.org/gmane.comp.lang.haskell.ghc.devel/443
http://markmail.org/message/4qvegvx32lhlo66g#query:+page:1+mid:bwdgykv4g2hzqg5t+state:results



On Thu, Sep 5, 2013 at 4:33 AM, Simon Peyton-Jones <simonpj at microsoft.com>wrote:

> | > Can I ask what the Cabal team's position is with respect to the
> | question of allowing the same package to be installed several times,
> | each compiled against a different collection of dependencies?
> |
> | I think that we all agree that in the long term a Nix-like package
> | database is the ideal solution to the "Cabal hell" problem (I even
> | mentioned this in the "Future Work" section of the post you linked).
> | However, it seems to be much harder to implement than sandboxes.
>
> I have not read the full GSoC page (thanks for that link), but are you all
> convinced that it *needs* to be that hard?
>
> The fundamental idea is, after all, so simple!  (I could elaborate.)
>  Perhaps the GSoc project was trying to be more ambitious.
>
> Or maybe I'm simply under-estimating.  But fundamentally it seems simple,
> so I'm suggesting we should perhaps try a bit harder to ferret out the
> underlying simplicity rather than assuming it must be hard.
>
> Simon
>
>
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20130905/9e1aa570/attachment.htm>


More information about the cabal-devel mailing list