Build breakage due to mtl upper bound about http

[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" [email protected]
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)

[hsenag]

From my point of view,
(1) Figuring out the correct upper bounds for each release
(2) Deciding what I feel about the after-the-fact-editing, as it does seem a bit evil never mind, if it's in general use anyway and people think it works it's not worth worrying about :-)