On 02/23/2013 08:08 PM, Nick Coghlan wrote: > On Sun, Feb 24, 2013 at 4:43 AM, Daniel Holth <dho...@gmail.com> wrote: >> There simply must be a way to spell "equals" that means "equals". It will be >> used when that so-called security release broke my application that >> integrates said library in a way that doesn't even expose the flaw. >> >> Plone depends on hundreds of libraries that probably only use >= or no >> version at all in their setup.py. Then the buildout.cfg ships with the == >> versions of all the libraries that the Plone release team actually tested. >> == is not the common plague that you fear. > > The core problem with making "==" strict is that it either makes "!=" > useless by allowing "(!=1.3)" to match "1.3.1", or it breaks the > invariant that "!=" is the logical inverse of "==", by having both > "(==1.3)" and "(!=1.3)" reject "1.3.1". I don't consider either > acceptable, which is why I switched the PEP to simple string prefix > matching for both [snip] > If a true exact version match is needed in order to be completely > certain about avoiding potentially broken upstream releases, then you > can use "(X.Y, < X.Y.post0)" rather than "(==X.Y)". Really though, > that level of pre-emptive quality assurance is better handled by using > a private curated index (or even a per-application index) where you > don't allow new versions to be uploaded until you've already tested > them.
If PEP 426 dependency version requirements are meant to support applications as well as libraries, I very much agree with Daniel that a real, strict == is critical, and should be the default behavior of ==. I don't think "it makes != useless" is a sufficient argument to make == behave surprisingly; in my experience, the need for != is quite rare, and it makes more sense to require multi-clause workarounds for !=, rather than for the simple "this is what I want, don't you dare pick anything else" case, which is quite common. If you are dead-set against making == strict by default, then I think we need a (gulp) === or similar. Requiring multi-clause workarounds or curated package archives for strict dependency pinning is unacceptable, IMO. Carl _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
