What's next?

[Johan Tibell]

You raise a good point that sandboxing only addresses the issue of
conflicts between two projects (that want to use different
dependencies), but not the issue of actually using two different
versions of a package (at different versions) in a single project*.
The latter is valuable but also a bit tricky. We'd need to make sure
that the two versions of the dependencies are private dependencies of
some other dependencies. For example, it's OK to use two different
versions of Parsec as long as you don't pass values from one version
to the other.

I think what really need is people who have the time to tackle the
issues on the wiki (there are quite a few). It's not going to be me
(although I can provide input on the design) as I don't have the time.

* We don't need to worry about the case of using two instances of the
same version of a package in a sandbox, as we can always rebuild all
packages such that they can use the same instance.

On Thu, Sep 5, 2013 at 3:52 PM, Yuri de Wit <ydewit at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel
>