<div dir="ltr"><div><div>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.<br><br></div>And arguments about "it shouldn't happen with the PVP" don't hold, because it does happen, PVP is a human judgement thing.<br><br></div>Alan<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 9, 2016 at 10:01 AM, Erik Hesselink <span dir="ltr"><<a href="mailto:hesselink@gmail.com" target="_blank">hesselink@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What do you expect will be the distribution of 'soft' and 'hard' upper<br>
bounds? In my experience, all upper bounds currently are 'soft' upper<br>
bounds. They might become 'hard' upper bounds for a short while after<br>
e.g. a GHC release, but in general, if a package maintainer knows that<br>
a package fails to work with a certain version of a dependency, they<br>
fix it.<br>
<br>
So it seems to me that this is not so much a choice between 'soft' and<br>
'hard' upper bounds, but a choice on what to do when you can't resolve<br>
dependencies in the presence of the current (upper) bounds. Currently,<br>
as you say, we give pretty bad error messages. The alternative you<br>
propose (just try) currently often gives the same result in my<br>
experience: bad error messages, in this case not from the solver, but<br>
unintelligible compiler errors in an unknown package. So it seems the<br>
solution might just be one of messaging: make the initial resolver<br>
error much friendlier, and give a suggestion to use e.g.<br>
--allow-newer=foo. The opposite might also be interesting to explore:<br>
if installing a dependency (so not something you're developing or<br>
explicitly asking for) fails to install and doesn't have an upper<br>
bound, suggest something like --constaint=foo<x.y.<br>
<br>
Do you have different experiences regarding the number of 'hard' upper<br>
bounds that exist?<br>
<br>
Regards,<br>
<br>
Erik<br>
<div class="HOEnZb"><div class="h5"><br>
On 8 June 2016 at 22:01, Michael Sloan <<a href="mailto:mgsloan@gmail.com">mgsloan@gmail.com</a>> wrote:<br>
> Right, part of the issue with having dependency solving at the core of your<br>
> workflow is that you never really know who's to blame.  When running into<br>
> this circumstance, either:<br>
><br>
> 1) Some maintainer made a mistake.<br>
> 2) Some maintainer did not have perfect knowledge of the future and has not<br>
> yet updated some upper bounds.  Or, upper bounds didn't get retroactively<br>
> bumped (usual).<br>
> 3) You're asking cabal to do something that can't be done.<br>
> 4) There's a bug in the solver.<br>
><br>
> So the only thing to do is to say "something went wrong".  In a way it is<br>
> similar to type inference, it is difficult to give specific, concrete error<br>
> messages without making some arbitrary choices about which constraints have<br>
> gotten pushed around.<br>
><br>
> I think upper bounds could potentially be made viable by having both hard<br>
> and soft constraints.  Until then, people are putting 2 meanings into one<br>
> thing.  By having the distinction, I think cabal-install could provide much<br>
> better errors than it does currently.  This has come up before, I'm not sure<br>
> what came of those discussions.  My thoughts on how this would work:<br>
><br>
> * The dependency solver would prioritize hard constraints, and tell you<br>
> which soft constraints need to be lifted.  I believe the solver even already<br>
> has this.  Stack's integration with the solver will actually first try to<br>
> get a plan that doesn't override any snapshot versions, by specifying them<br>
> as hard constraints.  If that doesn't work, it tries again with soft<br>
> constraints.<br>
><br>
> * "--allow-soft" or something would ignore soft constraints.  Ideally this<br>
> would be selective on a per package / upper vs lower.<br>
><br>
> * It may be worth having the default be "--allow-soft" + be noisy about<br>
> which constraints got ignored.  Then, you could have a "--pedantic-bounds"<br>
> flag that forces following soft bounds.<br>
><br>
> I could get behind upper bounds if they allowed maintainers to actually<br>
> communicate their intention, and if we had good automation for their<br>
> maintenance.  As is, putting upper bounds on everything seems to cause more<br>
> problems than it solves.<br>
><br>
> -Michael<br>
><br>
> On Wed, Jun 8, 2016 at 1:31 AM, Ben Lippmeier <<a href="mailto:benl@ouroborus.net">benl@ouroborus.net</a>> wrote:<br>
>><br>
>><br>
>> On 8 Jun 2016, at 6:19 pm, Reid Barton <<a href="mailto:rwbarton@gmail.com">rwbarton@gmail.com</a>> wrote:<br>
>><br>
>>>  Suppose you maintain a library that is used by a lot of first year uni<br>
>>> students (like gloss). Suppose the next GHC version comes around and your<br>
>>> library hasn’t been updated yet because you’re waiting on some dependencies<br>
>>> to get fixed before you can release your own. Do you want your students to<br>
>>> get a “cannot install on this version” error, or some confusing build error<br>
>>> which they don’t understand?<br>
>><br>
>><br>
>> This is a popular but ultimately silly argument. First, cabal dependency<br>
>> solver error messages are terrible; there's no way a new user would figure<br>
>> out from a bunch of solver output about things like "base-4.7.0.2" and<br>
>> "Dependency tree exhaustively searched" that the solution is to build with<br>
>> an older version of GHC.<br>
>><br>
>><br>
>> :-) At least “Dependency tree exhaustively searched” sounds like it’s not<br>
>> the maintainer’s problem. I prefer the complaints to say “can you please<br>
>> bump the bounds on this package” rather than “your package is broken”.<br>
>><br>
>> Ben.<br>
>><br>
>><br>
>> _______________________________________________<br>
>> ghc-devs mailing list<br>
>> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>