Support build-depends /= operation

[ndmitchell]

The build-depends supports the operators ==, >=, >, <, <=, but not /=. Supporting that final operator would be handy, for when you know a particular version of the library is broken.

[23Skidoo]

Agreed, that would be handy.

[hvr]

While I agree that the missing /= operator seems like an asymmetry, I'm not sure the stated purpose (i.e. for build-depends) is really justified (and ultimately I think this is why it never got added in the first place): It's the wrong side of the equation to have the many consumers declare a broken library version, instead of marking the single producer broken. This doesn't scale; If a specific release is broken, we can simply declare it broken by annotating this at the source via Hackage revisions, rather than trying to cure the symptom showing up in all its reverse dependencies...

While I don't see the benefit for build-depends, I can see this being useful for use within --constraints, when you're trying to force the solver into a different solution.

[ndmitchell]

@hvr, while I agree that it's not common, it is sometimes useful. Imagine if a library breaks a particular obscure usage, or has a performance/memory regression when called in a weird way. The author might not want to declare it broken for all, but a particular consumer might want to declare it broken for them.

Anyway, symmetry alone seems like a good reason to have it.

[hvr]

Just for the record (as I believe this to be common knowledge): /= a.b.c.d can be achived right now as it's basically syntax-sugar for/equivalent to (< a.b.c.d || > a.b.c.d). So adding /= would be primarily about convenience and expressibility; it doesn't enable something we cannot do already now.

However, there's been discussions about adding a more generic negation operator, so you could say:

build-depends: foo !(== 1.2.*), == 1.*

to express (>= 1 && < 1.2) || (>= 1.3 && < 2) in a different way; i.e. all 1.* versions expect the 1.2.* range. We do have already the combinators &&, ||, and grouping (/); I'd argue for this too, for symmetries sake to complete the algebra, would seem like a good reason to have ! ! :-)

[23Skidoo]

The one time I had a need for something like this was to avoid the versions of hashable that use SipHash, because they sometimes segfault. Those are still not marked broken on Hackage, but the bug is present in more than one version (>= 1.2.0.0 && < 1.2.0.9), so /= wouldn't help very much (and neither would something like /= 1.2.0.*, because that catches more than I want). But I think /= could be useful in some situations.

[hvr]

But then you could say

build-depends: hashable !(>= 1.2.0.0 && < 1.2.0.9)

with the ! operator which is less error-prone (people often mix up >=/> and </<=) that manually inverting the constraint as in

build-depends: hashable (< 1.2.0.0 || >= 1.2.0.9)

however, given that's a range at the start of a major version, you'd rather say more idiomatically:

build-depends: hashable >= 1.2.0.9 && < 1.3

or even

build-depends: hashable ^>= 1.2.0.9

[23Skidoo]

build-depends: hashable >= 1.2.0.9 && < 1.3 is what I think we ended up doing, though that package also supported hashable-1.1.* for a little while. Generalised negation with ! could be also useful, I think. I kinda like /= too because it expresses intent very clearly.