[Haskell-cafe] Checking minimum package bounds
mwm at mired.org
Sat Jul 5 19:51:54 UTC 2014
On Sat, Jul 5, 2014 at 2:37 PM, Omari Norman <omari at smileystation.com>
> 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
older one, especially if all I use are basic functions like "pack" that
have been around at least since, say. text-0.11.
That's because those bounds are basically "wrong". But you've
highlighted the problem right here:
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe