[Haskell-cafe] How to determine correct dependency versions for a library?

[Erik Hesselink]

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.

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).

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.

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.

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).

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.

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.

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.

Erik


On Sat, Nov 10, 2012 at 5:16 PM, Roman Cheplyaka <roma at ro-che.info> wrote:

> * Erik Hesselink <hesselink at gmail.com> [2012-11-10 16:40:30+0100]
> > On Fri, Nov 9, 2012 at 5:52 PM, Roman Cheplyaka <roma at ro-che.info>
> wrote:
> >
> > > * Janek S. <fremenzone at poczta.onet.pl> [2012-11-09 17:15:26+0100]
> > > > but I am aware that if the library were to be released on Hackage I
> > > > would have to supply version numbers in the dependencies. The
> question
> > > > is how to determine proper version numbers?
> > >
> > > With the current state of affairs, your best bet is not to specify any
> > > version bounds, or specify only lower ones.
> > >
> > > Upper version bounds much more often break things that fix things.
> > >
> >
> > I'd like to ask people not to do this. What you're doing then is moving
> the
> > burden from the maintainer (who has to test with new versions and relax
> > dependencies) to the users of the library (who will be faced with
> breakages
> > when new incompatible dependencies are released).
>
> The trouble is, when things break, they break either way — so I simply
> propose to reduce the probability of things breaking.
>
> I know, I know, the theory is that Cabal magically installs the right
> versions for you. However, in practice it often can't do that due to
> various reasons (base libraries, package reinstalls etc.)
>
> I'm not trying to shift the burden from the maintainer — I simply know
> from experience that maintainers are not nearly as quick and responsible
> as would be required for such scheme to work, so as a *user* I'd prefer
> that they omit upper bounds — at least until the --ignore-constraints
> option is implemented.
> (https://github.com/haskell/cabal/issues/949)
>
> Roman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121112/afde9551/attachment.htm>