On 5/12/14, 12:21 PM, Danny Navarro wrote:
On Mon, May 12, 2014 at 4:13 PM, Gabriel Gonzalez <[email protected]> wrote:
There are two issues with using `cabal freeze`:
1) It only works if `cabal` succeeds once, but the chance of it succeeding
goes down greatly if you remove upper bounds
That's the whole point of `cabal freeze`, right? If you build it with
a set of dependencies and you pin them, it should always build
flawlessly with that set. That should be good enough for critical
applications that need to be frequently deployed.
When not using `cabal freeze`, with dependent packages, you can always
use a CI, like Travis, that notifies of build breakage with new
dependency versions. And in that case it should be very clear where
the problem is, but when you have a complex dependency graph with
upper bounds, and for some reason a lower version gets installed you
have to *manually* traverse the whole graph to find which dependency
is pulling that old version. In that case, in practice, the
dependencies may not be buildable because incompatibility among
versions. This happened to me with the new version of `exceptions` and
some `pipes` packages. In this cases the final package is not
buildable regardless of upper bounds, the only difference is that
without upper bounds.
The issue is that for large packages like `yesod`, it can be very
difficult to find the first successful build that you pin. Without
upper bounds the cabal dependency solver gets lost really quickly and
will very likely fail almost every time you try to build. Figuring out
how to get the first frozen build working is incredibly difficult
because of this.
As an experiment, you can try disabling upper bounds for yesod and all
of its dependencies using cabal and see if it compiles correctly.
The packages that set no upper bounds are "selfish", meaning that they
are easier on their direct maintainers, but they are incredibly annoying
for downstream libraries that depend on them.
2) Once you remove upper bounds from a package it makes `cabal` much more
likely to fail on a permanent basis. Adding just one package in the history
that has no upper bound means that cabal will always consider that package
when it is trying to work around that upper bound, even if it's a really old
package.
Maybe I'm wrongly assuming that nowadays everybody is installing
everything in cabal sandboxes. I find myself continuously removing and
creating sandboxes, otherwise I don't know how I'd keep my sanity :)
But I realize there may still be people not using them. Are there many
out there?
This is orthogonal to sandboxes.
Think of it this way: cabal needs as much information as necessary to do
a good job. When you remove upper bounds you are depriving the
dependency solver of useful information that it needs to do its job
effectively.
Also, if I remember correctly they are adding (or maybe already added) a
flag to have `cabal` ignore upper bounds, which I think is the best
solution.
You are right, with that flag is like not having upper bounds at all,
so I think I'll set it as a default option for my `cabal`
configuration :)
But all in all, I don't intend to convince anybody of removing upper
bounds, I understand your point for having upper bounds and I think
they are valid points even though I personally prefer to deal with the
issues of not having them. Both solutions are far from an ideal
solution to dependency handling with `cabal` which I think it goes
much deeper.
On 05/12/2014 04:46 AM, Danny Navarro wrote:
My intention is not to start a discussion about whether upper limit
bounds is better than not having them (I prefer to not have them
though), but after the hairy process of updating some `pipes` packages
to `transfomers-0.4`, I was wondering if the new `cabal freeze`[1]
feature would cover the use cases for which upper limits are currently
used.
With cabal freeze we could pin the versions for which we are sure it
builds, while allowing easier upgrades for packages which use the
dependency. This doesn't guarantee that there won't be breakages, but
at least, IMHO, the dependencies of packages with many `pipes`
dependencies will be easier to update. Notice that in practice upper
limits doesn't guarantee flawless builds either.
[1]: http://blog.johantibell.com/2014/04/announcing-cabal-120.html
--
You received this message because you are subscribed to the Google Groups "Haskell
Pipes" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
