[Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator

[Nick Coghlan]

I realised globbing won't work easily, due to alpha/beta/release candidates
missing the preceding dot, so 1.1.1.* wouldn't match versions like 1.1.1c1,
while leaving the dot out would mean 1.1.1* matching versions like 1.1.11
(it also means the old PEP 345 default behaviour and the current "=="
behaviour aren't *quite* simple prefix matching, since they shouldn't match
a trailing numeric component with extra digits).

Accordingly, I'm considering adding "is" as the comparison operator to say
"this version, exactly this version, accept no substitutes".

Cheers,
Nick.
 On 26 Feb 2013 08:42, "Daniel Holth" <dholth at gmail.com> wrote:

> We have a potential solution from node which is to allow limited globs in
> version matches 1.0.*
> On Feb 25, 2013 3:04 PM, "Carl Meyer" <carl at oddbird.net> wrote:
>
>> On 02/23/2013 08:08 PM, Nick Coghlan wrote:
>> > On Sun, Feb 24, 2013 at 4:43 AM, Daniel Holth <dholth at 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 at python.org
>> http://mail.python.org/mailman/listinfo/distutils-sig
>>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130226/6a66595b/attachment-0001.html>