<p dir="ltr">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).</p>

<p dir="ltr">Accordingly, I'm considering adding "is" as the comparison operator to say "this version, exactly this version, accept no substitutes".</p>
<p dir="ltr">Cheers,<br>
Nick.<br>
</p>
<div class="gmail_quote">On 26 Feb 2013 08:42, "Daniel Holth" <<a href="mailto:dholth@gmail.com">dholth@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">We have a potential solution from node which is to allow limited globs in version matches 1.0.*</p>
<div class="gmail_quote">On Feb 25, 2013 3:04 PM, "Carl Meyer" <<a href="mailto:carl@oddbird.net" target="_blank">carl@oddbird.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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