Why upper bound version numbers?

[Michael Sloan]

Right, part of the issue with having dependency solving at the core of your
workflow is that you never really know who's to blame.  When running into
this circumstance, either:

1) Some maintainer made a mistake.
2) Some maintainer did not have perfect knowledge of the future and has not
yet updated some upper bounds.  Or, upper bounds didn't get retroactively
bumped (usual).
3) You're asking cabal to do something that can't be done.
4) There's a bug in the solver.

So the only thing to do is to say "something went wrong".  In a way it is
similar to type inference, it is difficult to give specific, concrete error
messages without making some arbitrary choices about which constraints have
gotten pushed around.

I think upper bounds could potentially be made viable by having both hard
and soft constraints.  Until then, people are putting 2 meanings into one
thing.  By having the distinction, I think cabal-install could provide much
better errors than it does currently.  This has come up before, I'm not
sure what came of those discussions.  My thoughts on how this would work:

* The dependency solver would prioritize hard constraints, and tell you
which soft constraints need to be lifted.  I believe the solver even
already has this.  Stack's integration with the solver will actually first
try to get a plan that doesn't override any snapshot versions, by
specifying them as hard constraints.  If that doesn't work, it tries again
with soft constraints.

* "--allow-soft" or something would ignore soft constraints.  Ideally this
would be selective on a per package / upper vs lower.

* It may be worth having the default be "--allow-soft" + be noisy about
which constraints got ignored.  Then, you could have a "--pedantic-bounds"
flag that forces following soft bounds.

I could get behind upper bounds if they allowed maintainers to actually
communicate their intention, and if we had good automation for their
maintenance.  As is, putting upper bounds on everything seems to cause more
problems than it solves.

-Michael

On Wed, Jun 8, 2016 at 1:31 AM, Ben Lippmeier <benl at ouroborus.net> wrote:

>
> On 8 Jun 2016, at 6:19 pm, Reid Barton <rwbarton at gmail.com> wrote:
>
>  Suppose you maintain a library that is used by a lot of first year uni
>> students (like gloss). Suppose the next GHC version comes around and your
>> library hasn’t been updated yet because you’re waiting on some dependencies
>> to get fixed before you can release your own. Do you want your students to
>> get a “cannot install on this version” error, or some confusing build error
>> which they don’t understand?
>>
>
> This is a popular but ultimately silly argument. First, cabal dependency
> solver error messages are terrible; there's no way a new user would figure
> out from a bunch of solver output about things like "base-4.7.0.2" and
> "Dependency tree exhaustively searched" that the solution is to build with
> an older version of GHC.
>
>
> :-) At least “Dependency tree exhaustively searched” sounds like it’s not
> the maintainer’s problem. I prefer the complaints to say “can you please
> bump the bounds on this package” rather than “your package is broken”.
>
> Ben.
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160608/7d9cd473/attachment.html>