Hi.

QuickCheck's constraint is template-haskell >= 2.4, which doesn't explain why cabal wanted to install 2.6.0.0 when 2.7.0.0 was already present.

Also, I'd expect --avoid-reinstalls to stop it reinstalling anything, but apparently it doesn't do that with the modular solver.

Assuming the examples you gave are the ones that Hackage actually uses: Is it necessary that Hackage uses an unreleased and older version of cabal-install? I can't really tell right now what the differences between 0.13.3 and 0.14.0 are, but clearly, if the modular solver isn't the default, then there still are significant differences. AFAIK --avoid-reinstalls is completely ignored by the old solver, but *not* by the modular solver. For me, 2.6.0.0 is picked with --avoid-reinstalls *because* 2.7.0.0 is already present, and 2.6.0.0 isn't. In concrete terms, with Cabal-1.14.0, cabal-install-0.14.0 and a ghc-7.4.1-based Haskell Platform installation without further packages: $ cabal install --dry-run sbv Resolving dependencies... In order, the following would be installed: containers-0.5.0.0 (new version) mtl-2.1.2 (new version) strict-concurrency-0.2.4.1 (new package) syb-0.3.7 (new version) template-haskell-2.7.0.0 (reinstall) changes: containers-0.4.2.1 -> 0.5.0.0 QuickCheck-2.5 (new version) sbv-2.2 (new package) Warning: The following packages are likely to be broken by the reinstalls: ghc-7.4.1 haddock-2.10.0 QuickCheck-2.4.2 haskell-platform-2012.2.0.0 Use --force-reinstalls if you want to install anyway. $ cabal install --dry-run sbv --avoid-reinstalls -v Reading available packages... Choosing modular solver. Resolving dependencies... In order, the following would be installed: containers-0.5.0.0 (new version) mtl-2.1.2 (new version) strict-concurrency-0.2.4.1 (new package) syb-0.3.7 (new version) template-haskell-2.6.0.0 (new version) QuickCheck-2.5 (new version) sbv-2.2 (new package) I haven't had time to thoroughly look at this problem, but it currently seems to me like it's triggered by containers-0.5.0.0 and has nothing to do with QuickCheck. The containers package is a dependency of template-haskell. So if containers is upgraded to 0.5, then template-haskell-2.7.0.0 would have to be reinstalled. With --avoid-reinstalls, cabal-install will pick an older template-haskell, not knowing that this will lead to a failure at build time. There's really no other chance, because sbv-2.2 seems to depend on containers-0.5.0.0. With containers being a dependency of GHC core libraries such as template-haskell, there isn't currently a good option to use containers-0.5.0.0 with ghc-7.4. Using --avoid-reinstalls blindly or as a default flag is also unfortunately not a good idea in general. There are simply too many cases where installing older versions of packages (which is often the only thing that helps) is not really the solution you want. That's also the reason why it's not enabled by default. Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com

On Wed, Jul 18, 2012 at 10:19 AM, Ross Paterson wrote:

On Wed, Jul 18, 2012 at 06:50:31AM +0100, Andres Löh wrote:

...

Using --avoid-reinstalls blindly or as a default flag is also unfortunately not a good idea in general. There are simply too many cases where installing older versions of packages (which is often the only thing that helps) is not really the solution you want. That's also the reason why it's not enabled by default.

I need a combination of flags that I can use blindly with the greatest chance of success. The default doesn't work on packages like this one:

% cabal --version cabal-install version 0.14.0 using version 1.14.0 of the Cabal library % cabal install sbv-2.2 Resolving dependencies... In order, the following would be installed: HUnit-1.2.4.3 (new package) containers-0.5.0.0 (new version) random-1.0.1.1 (new package) strict-concurrency-0.2.4.1 (new package) syb-0.3.7 (new package) template-haskell-2.7.0.0 (reinstall) changes: containers-0.4.2.1 -> 0.5.0.0 QuickCheck-2.5 (new package) transformers-0.3.0.0 (new package) mtl-2.1.2 (new package) sbv-2.2 (new package) cabal: The following packages are likely to be broken by the reinstalls: ghc-7.4.1 Use --force-reinstalls if you want to install anyway.

I don't think you can install this package on 7.4. As Andres said, it requires containers 0.5, but ghc 7.4's base libraries (in this case, template-haskell) use containers 0.4, and can't be reinstalled. I guess your best bet is to use sbv-2.1, which depends on containers >= 0.3, or to unpack it and see if you can loosen the containers dependency and see if it still works with 0.4 So in short, no combination of flags will work in this case, I think. Failure is the best option. Erik

Is there any reason QuickCheck specifically requires containers >= 0.5? Perhaps its lower bound could be relaxed. On Wed, Jul 18, 2012 at 11:29 AM, Ross Paterson wrote:

On Wed, Jul 18, 2012 at 09:35:52AM +0100, Erik Hesselink wrote:

...

I don't think you can install this package on 7.4. As Andres said, it requires containers 0.5, but ghc 7.4's base libraries (in this case, template-haskell) use containers 0.4, and can't be reinstalled. I guess your best bet is to use sbv-2.1, which depends on containers >= 0.3, or to unpack it and see if you can loosen the containers dependency and see if it still works with 0.4

I'm talking about unattended automated builds, so tweaking isn't an option. On the other hand breaking the package environment isn't so bad, because I'm throwing it away after each build.

...

So in short, no combination of flags will work in this case, I think. Failure is the best option.

Actually --force-reinstalls does work in this case, and this thread began with Levent being unhappy with the failure option for his package, so I'm tempted to use that flag on all hackage builds.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Gregory Collins

I'm talking about unattended automated builds, so tweaking isn't an option. On the other hand breaking the package environment isn't so bad, because I'm throwing it away after each build.

I'm not convinced that we should try to build packages at any price. If they're likely to cause problems in a standard environment on a user machine, then isn't it better to see this reflected on Hackage?

...

So in short, no combination of flags will work in this case, I think. Failure is the best option.

Actually --force-reinstalls does work in this case, and this thread began with Levent being unhappy with the failure option for his package, so I'm tempted to use that flag on all hackage builds.

Does it produce a usable package and environment, or does it just work, but leave everything broken? I agree that using --force-reinstalls on Hackage might be an acceptable option, and it's probably better than using --avoid-reinstalls by default. However, it may still send the misleading message that a package "builds just fine" when it practice it doesn't. Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com

On Wed, Jul 18, 2012 at 09:35:52AM +0100, Erik Hesselink wrote:

I don't think you can install this package on 7.4. As Andres said, it requires containers 0.5, but ghc 7.4's base libraries (in this case, template-haskell) use containers 0.4, and can't be reinstalled. I guess your best bet is to use sbv-2.1, which depends on containers >= 0.3, or to unpack it and see if you can loosen the containers dependency and see if it still works with 0.4

So the moral of this story is that libraries should avoid depending on features of the containers package that have not yet been released with GHC.