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

[Daniel Holth]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130225/e1651f36/attachment-0001.html>