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