tl;dr: Breakages without upper bounds are annoying and hard to solve for package consumers. With upper bounds, and especially with sandboxes, breakage is almost non-existent.<br><br>I don't see how things break with upper bounds, at least in the presence of sandboxes. If all packages involved follow the PVP, a build that worked once, will always work. Cabal 0.10 and older had problems here, but 0.14 and later will always find a solution to the dependencies if there is one (if you set max-backjumps high enough).<br>
<br>Without sandboxes, cabal might have to reinstall a package with different dependencies, breaking other packages. It will currently warn against this. Future versions will hopefully tell you about the sandboxing features that can also be used to avoid this.<br>
<br>In contrast, without upper bounds a packages is almost sure to fail to compile at some point. A user will then get compile errors outside his own code, somewhere in the middle of his dependency chain. Depending on his expertise, this will be either hard or impossible to fix. In particular, it is not clear that too lenient dependencies are the problem, and if it is clear, you do not know which ones.<br>
<br>So I still see this as a tradeoff between the interests of package developers/maintainers (upper bounds give more testing/release work, and also, they want to use the latest versions) versus package users/companies (who want a build to work, but often don't care about the bleeding edge).<br>
<br>Personnaly, I fall in both groups, and have experienced both problems. At Silk, we have (internal) packages with huge dependency chains (we depend on both happstack and snap). With cabal 0.10, this was a nightmare. Since 0.14, we've had no breakages, except from packages that do not specify upper bounds! We're fairly up-to-date with GHC versions: we're on 7.4 now, but with no immediate plans to switch to 7.6. Switching to a new GHC version is a bit of work, but we can decide when to do the work. Without upper bounds, our builds can break at any moment, and we have to fix it then and there to be able to continue working.<br>
<br>If you do have to use the bleeding edge (or a packages uses really outdated dependencies) you can also use sandboxes to your advantage. Just 'cabal unpack' the problematic package, change the dependencies and add the resulting source package to your sandbox. This is what we do when we test out a new GHC version. We also try to contribute fixes back upstream.<br>
<br>This is why I ask for people to specify upper bounds. They mean that packages keep working, and they prevent users from getting incomprehensible, badly timed build failures.<br><br>Erik<br><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Sat, Nov 10, 2012 at 5:16 PM, Roman Cheplyaka <span dir="ltr"><<a href="mailto:roma@ro-che.info" target="_blank">roma@ro-che.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Erik Hesselink <<a href="mailto:hesselink@gmail.com">hesselink@gmail.com</a>> [2012-11-10 16:40:30+0100]<br>
<div><div class="h5">> On Fri, Nov 9, 2012 at 5:52 PM, Roman Cheplyaka <<a href="mailto:roma@ro-che.info">roma@ro-che.info</a>> wrote:<br>
><br>
> > * Janek S. <<a href="mailto:fremenzone@poczta.onet.pl">fremenzone@poczta.onet.pl</a>> [2012-11-09 17:15:26+0100]<br>
> > > but I am aware that if the library were to be released on Hackage I<br>
> > > would have to supply version numbers in the dependencies. The question<br>
> > > is how to determine proper version numbers?<br>
> ><br>
> > With the current state of affairs, your best bet is not to specify any<br>
> > version bounds, or specify only lower ones.<br>
> ><br>
> > Upper version bounds much more often break things that fix things.<br>
> ><br>
><br>
> I'd like to ask people not to do this. What you're doing then is moving the<br>
> burden from the maintainer (who has to test with new versions and relax<br>
> dependencies) to the users of the library (who will be faced with breakages<br>
> when new incompatible dependencies are released).<br>
<br>
</div></div>The trouble is, when things break, they break either way — so I simply<br>
propose to reduce the probability of things breaking.<br>
<br>
I know, I know, the theory is that Cabal magically installs the right<br>
versions for you. However, in practice it often can't do that due to<br>
various reasons (base libraries, package reinstalls etc.)<br>
<br>
I'm not trying to shift the burden from the maintainer — I simply know<br>
from experience that maintainers are not nearly as quick and responsible<br>
as would be required for such scheme to work, so as a *user* I'd prefer<br>
that they omit upper bounds — at least until the --ignore-constraints<br>
option is implemented.<br>
(<a href="https://github.com/haskell/cabal/issues/949" target="_blank">https://github.com/haskell/cabal/issues/949</a>)<br>
<span class="HOEnZb"><font color="#888888"><br>
Roman<br>
</font></span></blockquote></div><br></div>