<div dir="ltr"><div style>fyi, below you can find an expanded list of related links.<br></div><div><br></div><div style>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).</div>
<div style><br></div><div><div><br></div><div><div>GSoC 2012 - Enable GHC to use multiple instances of a package for compilation - Philipp Schuster</div><div><a href="http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/phischu/1">http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/phischu/1</a></div>
<div><a href="http://www.google-melange.com/gsoc/project/google/gsoc2012/phischu/19001">http://www.google-melange.com/gsoc/project/google/gsoc2012/phischu/19001</a></div><div><a href="https://github.com/phischu/cabal">https://github.com/phischu/cabal</a></div>
<div><br></div><div>GHC Commentary</div><div><a href="http://ghc.haskell.org/trac/ghc/wiki/Commentary/Packages/MultiInstances">http://ghc.haskell.org/trac/ghc/wiki/Commentary/Packages/MultiInstances</a></div><div><a href="http://ghc.haskell.org/trac/ghc/wiki/Commentary/Packages">http://ghc.haskell.org/trac/ghc/wiki/Commentary/Packages</a></div>
<div><a href="http://ghc.haskell.org/trac/ghc/wiki/Commentary/GSoCMultipleInstances">http://ghc.haskell.org/trac/ghc/wiki/Commentary/GSoCMultipleInstances</a></div><div><br></div><div>Mailing list</div><div><a href="http://comments.gmane.org/gmane.comp.lang.haskell.ghc.devel/443">http://comments.gmane.org/gmane.comp.lang.haskell.ghc.devel/443</a></div>
<div><a href="http://markmail.org/message/4qvegvx32lhlo66g#query:+page:1+mid:bwdgykv4g2hzqg5t+state:results">http://markmail.org/message/4qvegvx32lhlo66g#query:+page:1+mid:bwdgykv4g2hzqg5t+state:results</a></div></div></div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 5, 2013 at 4:33 AM, Simon Peyton-Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">| > Can I ask what the Cabal team's position is with respect to the<br>
| question of allowing the same package to be installed several times,<br>
| each compiled against a different collection of dependencies?<br>
|<br>
| I think that we all agree that in the long term a Nix-like package<br>
| database is the ideal solution to the "Cabal hell" problem (I even<br>
| mentioned this in the "Future Work" section of the post you linked).<br>
| However, it seems to be much harder to implement than sandboxes.<br>
<br>
</div>I have not read the full GSoC page (thanks for that link), but are you all convinced that it *needs* to be that hard?<br>
<br>
The fundamental idea is, after all, so simple! (I could elaborate.) Perhaps the GSoc project was trying to be more ambitious.<br>
<br>
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.<br>
<span class="HOEnZb"><font color="#888888"><br>
Simon<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
cabal-devel mailing list<br>
<a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/cabal-devel" target="_blank">http://www.haskell.org/mailman/listinfo/cabal-devel</a><br>
</div></div></blockquote></div><br></div>