Why upper bound version numbers?

[Alan & Kim Zimmerman]

I think "hard" upper bounds would come about in situations where a new
version of a dependency is released that breaks things in a package, so
until the breakage is fixed a hard upper bound is required.  Likewise for
hard lower bounds.

And arguments about "it shouldn't happen with the PVP" don't hold, because
it does happen, PVP is a human judgement thing.

Alan


On Thu, Jun 9, 2016 at 10:01 AM, Erik Hesselink <hesselink at gmail.com> wrote:

> What do you expect will be the distribution of 'soft' and 'hard' upper
> bounds? In my experience, all upper bounds currently are 'soft' upper
> bounds. They might become 'hard' upper bounds for a short while after
> e.g. a GHC release, but in general, if a package maintainer knows that
> a package fails to work with a certain version of a dependency, they
> fix it.
>
> So it seems to me that this is not so much a choice between 'soft' and
> 'hard' upper bounds, but a choice on what to do when you can't resolve
> dependencies in the presence of the current (upper) bounds. Currently,
> as you say, we give pretty bad error messages. The alternative you
> propose (just try) currently often gives the same result in my
> experience: bad error messages, in this case not from the solver, but
> unintelligible compiler errors in an unknown package. So it seems the
> solution might just be one of messaging: make the initial resolver
> error much friendlier, and give a suggestion to use e.g.
> --allow-newer=foo. The opposite might also be interesting to explore:
> if installing a dependency (so not something you're developing or
> explicitly asking for) fails to install and doesn't have an upper
> bound, suggest something like --constaint=foo<x.y.
>
> Do you have different experiences regarding the number of 'hard' upper
> bounds that exist?
>
> Regards,
>
> Erik
>
> On 8 June 2016 at 22:01, Michael Sloan <mgsloan at gmail.com> wrote:
> > 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
> >>
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> _______________________________________________
> 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/20160609/cc902bd0/attachment.html>