Don't implement allow-newer/allow-older by modifying PackageDescription

[ezyang]

It seems cleaner to hook it straight into the dep solver, rather than try to ninja it in by package description modification. If you do it by modification, you have to worry about making sure the "correct" package description is used anywhere you want to look at deps, and sometimes you get spurious warnings because it looks like you modify build-depends which affects our source level checks, but actually we didn't.

The lack of cleanliness here is hurting me because I want BuildInfo to reflect the written syntax as closely as possible (when I make the modification for #4155), but I have to keep targetBuildDepends around as a real field if people are editing it.

Previously @kosmikus requested this in #3466.

[Ericson2314]

This would be in the same spirit as removing cabal-install's mysterious other injected extra bounds which cause #4169 right?

[ezyang]

Yep, I think so, thanks for posting the reference!

[23Skidoo]

The problem here is that we won't be able to implement ./Setup.hs configure --alow-newer in this way, and IIRC that interface is used by Stack (it was added per @snoyberg's request).

[hvr]

@23Skidoo relevant: #3581

[23Skidoo]

OK, if Stack doesn't need that interface, then we can remove it.

[Ericson2314]

Because of #4527, this only covers other cases of modifying bounds in situ like #4169, and #4383 if it's merged, right?

[23Skidoo]

#4527 only removed the --allow-{newer,older} command-line options from setup scripts, the main issue this ticket is about is still there.

[Ericson2314]

@23Skidoo Ah the code in Cabal is still there and not dead via something else?

[23Skidoo]

Yes, it's spread across lib:Cabal and cabal-install. See D.C.Dependency.removeBounds, which uses D.PD.transformAllBuildDepends.

[Ericson2314]

Thanks!