I don't see much discussion on lower bounds. Lower bounds that are needlessly restrictive can get in the way too. For instance, I could just slap "text >= 1.1 && < 1.2" on my package, but this makes things needlessly hard for someone trying to make my package work in conjunction with an
On Sat, Jul 5, 2014 at 2:37 PM, Omari Norman
Does anyone have a best practice for testing and verifying lower bounds? Testing the lower bounds and the upper ones is a challenge.
Upper bounds, of course, can only be tested to the most recent
version. Lower bounds can be tested, but - well, it's not easy.
I have a suspicion (could well be wrong) the debate about upper bounds
comes down to how the bounds are interpreted: are they "known to work"
or "known to not work"? "cabal build" treats them as "known to not
work", as it refuses to try to build things when there are
dependencies that are "out of bounds". But "cabal init" and most
developers seem to treat them as "known to work".
Maybe cabal needs two sets of bounds: One for "known to work" and one
for "known to not work". If every dependency is "known to work", it
builds as now. If some dependency is in the "known to not work" set,
then it refuses to build with an error. If some dependency is not
"known to work" but no dependency is "known to not work", then maybe
it issues warnings for those not "known to work", or maybe it errors
out like now but there's a flag to force it to build anyway, or maybe
it builds if it was configured with tests enabled but not otherwise.