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 (this also brings it back into line with the default version comparison behaviour specified in PEP 345 - I haven't yet reinstated that PEPs commentary about why this makes it important to include the ".0" suffix on the first release in a series so people can easily depend specifically on that release without allowing later releases in the series, but I'm definitely considering it). 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. > As a aside pkg_resources probably needs an operator [that might be removed > when generating PKG-INFO] for use in setup.py install_requires. Setuptools > parses distname [OPERATOR version] not distname [OPERATOR? version] pkg_resources can either use "~>" as Ruby do, or (and I think this would make more sense, but I'm not writing the code), it could be updated to accept the standard syntax directly, allowing users to easily request either classic pkg_resources semantics or PEP 426 semantics. The parentheses aren't *just* about making the association of version specifiers with the preceding package name clearer, they're also about being clear that the existing pkg_resources semantics aren't being adopted wholesale. (I also just noticed that distribute's dependency declaration documentation states the behaviour of mutually contradictory version constraints in pkg_resources is undefined - that doesn't make sense, so I'll be adding an explicit statement to the PEP that mutually contradictory clauses in a version specifier are an error) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
