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. > 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? > > 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 >> > -- Danny Navarro | http://dannynavarro.net -- 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].
