Hi Simon, I don't think it's being actively worked on. Duncan and I chat about it once in a while when we meet in person, but we don't have the cycles to do it. On Thu, Nov 28, 2013 at 12:41 PM, Simon Peyton-Jones wrote:

I’m thrilled that there so much Cabal activity!

Is anyone working on, or interested in, the issue of compiling and installing the same package against different dependencies? (There was a Google SoC project about this.) Cabal sandboxes address the same issue, but at some user cost. It should Just Work.

Simon

*From:* cabal-devel [mailto:cabal-devel-bounces@haskell.org] *On Behalf Of *Johan Tibell *Sent:* 27 November 2013 21:01 *To:* cabal-devel@haskell.org *Subject:* Should we aim for a new release in late January?

Hi,

Cabal development is continuing at a furious pace. There are lots of great things in master that I'd like to get out to users, such as

* relinking avoidance

* build -j

* ability to specify exact deps on the command line

* haskell-suite compiler support

* bug fixes

Here's an approximate list of commits (both Cabal and cabal-install) since the last release:

https://github.com/haskell/cabal/compare/Cabal-v1.18.1.2...master

It's not entirely accurate as some patches were cherry-picked onto the 1.18 branch and thus have different commit IDs.

-- Johan

Hi, I think it's non trivial due to us not having a nailed down design in several areas (i.e. it's not just coding work needed). If you look at the ToDo items at: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Packages/MultiInstances several of the ToDos don't have clear designs yet. For example: - instances of packages must install in a different location - install directory includes hash? - SDM: not done yet. One problem is that we don't know the hash until the package is built, but we need to know the install locations earlier because we bake them into Paths_foo.hs. - Simon and Andres discussed that one option is to let Cabal compute its own hash. However, then we'd have two hashes to deal with. Only using the Cabal-computed hash isn't an option either according to Simon, because apparently GHC's ABI hash computation is non-deterministic, so we might end up with situations where Cabal's hash is stable, but GHC computes an ABI-incompatible version. This is somewhat worrying ... - Duncan thinks that we should store both a package identity and a package ABI hash. Currently we form the package id from the name, version and ABI hash. We should store the ABI hash separately anyway because eventually we will want to know it, to know which packages are ABI compatible. So Cabal can compute a package Id in advance, however is sensible, and the ABI hash is calculated as now, after the build. The installation directory follows the package Id. and - GHC: discard conflicting instances during its shadowing phase - SDM: GHC will currently do *something* here, but it might end up with a result that the user didn't want/expect. One way to improve things is to prioritise packages that were installed more recently. - Andres suggests that GHC should be much cleverer, and look at the actual dependencies of the modules being compiled before deciding which packages to enable. This would almost certainly result in more things working and possibly less surprising behaviour sometimes, but Simon thinks that (a) it is too hard, (b) if users need this, they should use Cabal and its dependency resolver, which will do a good job, (c) you can often resolve problems by adding -package X, and (d) eventually we will want a system where users manage separate sessions, so they can set up an environment in which the packages they want are available. This has a lot in common with cabal-dev and sandboxes, so the mechanisms (and concepts) should be shared. (kosmikus: perhaps an alternative is to force the user to make an active decision in case of conflicts, i.e., to create a sandbox that exposes a consistent package set). -- Johan On Thu, Nov 28, 2013 at 1:12 PM, Simon Peyton-Jones wrote:

Is it really that many cycles? (Compared to all the other great stuff the Cabal team are doing.)

Simon

*From:* Johan Tibell [mailto:johan.tibell@gmail.com] *Sent:* 28 November 2013 12:07 *To:* Simon Peyton-Jones *Cc:* cabal-devel@haskell.org *Subject:* Re: Should we aim for a new release in late January?

Hi Simon,

I don't think it's being actively worked on. Duncan and I chat about it once in a while when we meet in person, but we don't have the cycles to do it.

On Thu, Nov 28, 2013 at 12:41 PM, Simon Peyton-Jones < simonpj@microsoft.com> wrote:

I’m thrilled that there so much Cabal activity!

Is anyone working on, or interested in, the issue of compiling and installing the same package against different dependencies? (There was a Google SoC project about this.) Cabal sandboxes address the same issue, but at some user cost. It should Just Work.

Simon

*From:* cabal-devel [mailto:cabal-devel-bounces@haskell.org] *On Behalf Of *Johan Tibell *Sent:* 27 November 2013 21:01 *To:* cabal-devel@haskell.org *Subject:* Should we aim for a new release in late January?

Hi,

Cabal development is continuing at a furious pace. There are lots of great things in master that I'd like to get out to users, such as

* relinking avoidance

* build -j

* ability to specify exact deps on the command line

* haskell-suite compiler support

* bug fixes

Here's an approximate list of commits (both Cabal and cabal-install) since the last release:

https://github.com/haskell/cabal/compare/Cabal-v1.18.1.2...master

It's not entirely accurate as some patches were cherry-picked onto the 1.18 branch and thus have different commit IDs.

-- Johan