<div dir="ltr">On Tue, Feb 26, 2013 at 8:17 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Feb 26, 2013 at 10:08 PM, Michael Foord <<a href="mailto:fuzzyman@gmail.com">fuzzyman@gmail.com</a>> wrote:<br>

> The current tools are strict with regards to equality - and in dependency<br>
> pinning I would see it as *surprising* that specifying "==1.3" installs some<br>
> version that isn't precisely 1.3. Having "==" mean approximately-equal,<br>
> instead of the-same-as, seems like a mistake to me.<br>
<br>
</div>The most palatable alternative I've seen so far is for a trailing ".*"<br>
to trigger prefix matching for == and != (it would be disallowed for<br>
anything else). It's *slightly* odd, because the "." is implied rather<br>
than explicit for alphas, betas and release candidates (a choice<br>
driven by the weight of existing practice on PyPI, as well as<br>
CPython's own conventions), but it's probably still a better idea than<br>
trying to change the meaning of "==".<br>
<br>
I *don't* like the idea of (== 1.3) and (== 1.3.0) being equivalent<br>
when (1.3) and (1.3.0) are substantially different, though. Instead,<br>
I'll reinstate a variant of the commentary from PEP 386 that pointed<br>
out the value of always publishing releases with a consistent number<br>
of components by including the trailing ".0".</blockquote><div><br></div><div style>I am still not convinced about the prefix behavior but realize that if we are using sensible consistently three-digit releases then there is no problem.</div>
<div style><br></div><div style>There is an algorithm for splitting "version parts" at either . or the transition from a number to a non-number or vice versa. In pkg_resources 1.1a1 and 1.1.a1 are the same.</div>
</div></div></div>