Build breakage due to mtl upper bound

[snoyberg]

Reproed on GHC 7.4.2, 7.6.3, 7.8.2. Using cabal-install 1.16 for the first two, 1.18 when using GHC 7.8.

Start with a clean package environment, then run:

cabal install cabal-install-1.16.0.2 --dry-run

Due to inconsistent upper bounds on transformers, the build plan selects HTTP-4000.0.7. At least on GHC 7.4.2, this package install ultimately fails with:

[ 7 of 15] Compiling Network.BufferType ( Network/BufferType.hs, dist/build/Network/BufferType.o )

Network/BufferType.hs:57:10:
    Illegal instance declaration for `BufferType String'
      (All instance types must be of the form (T a1 ... an)
       where a1 ... an are *distinct type variables*,
       and each type variable appears at most once in the instance head.
       Use -XFlexibleInstances if you want to disable this.)
    In the instance declaration for `BufferType String'
Failed to install HTTP-4000.0.7
cabal: Error: some packages failed to install:
HTTP-4000.0.7 failed during the building phase. The exception was:
ExitFailure 1
cabal-install-1.16.0.2 depends on HTTP-4000.0.7 which failed to install.

This is the exact same issue as #55. This problem is likely to cause wide-spread breakage until a new version of HTTP is released which is compatible with transformers 0.4.

[mightybyte]

And like issue #55, the real cause of this problem is the lack of upper bounds on HTTP-4000.0.7, not the presence of upper bounds on the current version of HTTP.

[snoyberg]

If you want to call that the real cause, that's fine. What's the real solution then?

[hsenag]

I've fixed the mtl dep.

Is there anything more I can do about this general problem with the old versions in the HTTP package? Otherwise I guess the remaining issue is one for cabal/hackage, not HTTP.

Pinging @tibbe - do we understand why the version preference you added before isn't helping in this situation?

[tibbe]

I filed a bug against cabal re the preference issue. I think it's due to a
misunderstanding of the desired behavior when the preference support was
implemented.

As for old http package version, you could release patched versions of old
http major releases. This would help a tiny bit as cabal has a soft
preference for newer version. However, today there exists no real mechanism
to fix build breakages due to omitting upper bound.
On May 8, 2014 8:55 AM, "Ganesh Sittampalam" notifications@github.com
wrote:

I've fixed the mtl dep.

Is there anything more I can do about this general problem with the old
versions in the HTTP package? Otherwise I guess the remaining issue is one
for cabal/hackage, not HTTP.

Pinging @tibbe https://github.com/tibbe - do we understand why the
version preference you added before isn't helping in this situation?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/64#issuecomment-42518631
.

[snoyberg]

@hsenag Thanks for getting the new version onto Hackage.

The reason the version preference doesn't work is documented here: haskell/cabal#1792. AFAICT, there are no plans to actually address that issue, which seems to mean that for the foreseeable future, every time a major version of an HTTP dependency is released, build plans will immediately start failing.

[hsenag]

OK, thanks - sounds like it just needs someone to implement the idea in the thread, so if this continues to cause pain perhaps someone will do that.

I don't think I'm willing to be forever maintaining a 4000.0.7 branch of HTTP to keep up to date with the latest code in dependencies, and I don't really want people to be randomly ending up with that old version.

If I could retrospectively fix the upper bounds on hackage, that would be something that's worth the effort.

[snoyberg]

Changing version bounds after-the-fact is not currently supported by Hackage, and I think the reason is because it's unknown how that may cause breakage for others. But specifically adding stricter bounds seems like it's more likely to cause breakage with the current toolset, so I'd be cautious about moving ahead with that.

[hsenag]

I guess if it is turned on then it would be because the toolset is thought to support it :-) If we'd had the stricter bounds all along the current situation would be much better.

[tibbe]

After-the-fact updating of .cabal files (and thus bounds) on Hackage, was implemented by Duncan. Turns out that his implementation had a bug and he hasn't had time to fix it yet.

[hvr]

Btw, what's keeping us now from fixing up all old HTTP package version's known-to-be-wrong cabal meta-data?

(Fwiw, something similar was done for mtl and template-haskell as soon as after-the-fact updating of .cabal files got enabled, as ancient mtl/template-haskell packages also didn't have upper bounds yet)