but look at this (using setuptools 8)
'1.7.dev1' in pkg_resources.Requirement.parse('foo=1.7')
False
'1.7.dev1' in pkg_resources.Requirement.parse('foo=1.7')
True
I believe the first example is a consequence of the following two
excerpts from the PEP [...] In both cases (by (2)
Thinking of 1.7 as greater than the 1.7 series sort of helps me as
well...
the problem with thinking of it this way is that you naturally want to
extend the concept to =, but it doesn't work.
If the concept were consistent, 1.7.dev1 would satisfy =1.7, but it
doesn't.
for =, the concept
the problem with thinking of it this way is that you naturally want to
extend the concept to =, but it doesn't work.
If the concept were consistent, 1.7.dev1 would satisfy =1.7, but it
doesn't.
I'm pretty sure it's consistent. For example, 1.7.2 doesn't satisfy
1.7, but it satisfies
On 25 Dec 2014 03:25, Marcus Smith qwc...@gmail.com wrote:
It *should* be being kept in sync with the published versions, but
Donald and I have just been working directly in the main PEP repo recently.
Hence my suggestion of moving it to GitHub - it's more likely to be kept
up to date there,
On 24 Dec 2014 05:27, Marcus Smith qwc...@gmail.com wrote:
just post edit suggestions here?
https://bitbucket.org/pypa/pypi-metadata-formats is not up to date
anymore
some other location?
It *should* be being kept in sync with the published versions, but Donald
and I have just been working
It *should* be being kept in sync with the published versions, but Donald
and I have just been working directly in the main PEP repo recently.
Hence my suggestion of moving it to GitHub - it's more likely to be kept
up to date there, and, unlike the master PEP repo, I'm happy to host the
On Dec 23, 2014, at 1:23 AM, Marcus Smith qwc...@gmail.com wrote:
In particular, , , ~=, and, when using a .*, the != and == use the number
of dots in the given specifier to indicate the precision of the specifier.
the PEP text is pretty clear on the precision concept for ~= and when
Yes but thanks to Marc it now provides a clear message as to why.
(Sent from my mobile)
On Dec 23, 2014 11:22 AM, James Bennett ubernost...@gmail.com wrote:
So, if PyPI has foo-1.7 and foo-1.7.1, does 1.7 just fail to find
anything installable?
___
On 22 December 2014 at 20:44, Marcus Smith qwc...@gmail.com wrote:
it would fail. you'd need 1.7.0
On Mon, Dec 22, 2014 at 12:36 PM, James Bennett ubernost...@gmail.com
wrote:
So, if PyPI has foo-1.7 and foo-1.7.1, does 1.7 just fail to find
anything installable?
I think the thing I'd
It also provides consistency with date-based versions. And versions aren't
decimals so thinking of them like that is not exactly useful.
On Dec 23, 2014 11:43 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 22 December 2014 at 20:44, Marcus Smith qwc...@gmail.com wrote:
it would fail. you'd need
On 23 Dec 2014, at 18:43, Paul Moore p.f.mo...@gmail.com wrote:
On 22 December 2014 at 20:44, Marcus Smith qwc...@gmail.com wrote:
it would fail. you'd need 1.7.0
On Mon, Dec 22, 2014 at 12:36 PM, James Bennett ubernost...@gmail.com
wrote:
So, if PyPI has foo-1.7 and foo-1.7.1, does
just post edit suggestions here?
https://bitbucket.org/pypa/pypi-metadata-formats is not up to date anymore
some other location?
On Tue, Dec 23, 2014 at 1:01 AM, Donald Stufft don...@stufft.io wrote:
On Dec 23, 2014, at 1:23 AM, Marcus Smith qwc...@gmail.com wrote:
In particular, , , ~=,
On 22 December 2014 at 20:20, Marcus Smith qwc...@gmail.com wrote:
In PEP440, foo-X.Y.Z does not satisfy the specifier fooX.Y (although it
satisfies foo=X.Y)
for example, foo-1.7.2 will not satisfy foo1.7, but it will satisfy
foo=1.7
for '' and '', PEP440 states that they are
On Dec 22, 2014, at 3:20 PM, Marcus Smith qwc...@gmail.com wrote:
In PEP440, foo-X.Y.Z does not satisfy the specifier fooX.Y (although it
satisfies foo=X.Y)
for example, foo-1.7.2 will not satisfy foo1.7, but it will satisfy
foo=1.7
for '' and '', PEP440 states that they are
On 22 December 2014 at 20:33, Donald Stufft don...@stufft.io wrote:
It’s true that pip doesn’t install pre-releases by default (assuming there
is any final releases available), but that doesn’t actually solve the
underlying problem - it just masks it. When people put ``foo8`` in their
it would fail. you'd need 1.7.0
On Mon, Dec 22, 2014 at 12:36 PM, James Bennett ubernost...@gmail.com
wrote:
So, if PyPI has foo-1.7 and foo-1.7.1, does 1.7 just fail to find
anything installable?
___
Distutils-SIG maillist -
On Dec 22, 2014, at 3:43 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 22 December 2014 at 20:33, Donald Stufft don...@stufft.io wrote:
It’s true that pip doesn’t install pre-releases by default (assuming there
is any final releases available), but that doesn’t actually solve the
underlying
This makes sense if you view 1.7 as encompassing all of the releases
1.7.0, 1.7.1, 1.7.2, etc. (and their variants). It's a bit like the
significant digits of a number. [1] You want the release to be
bigger than all releases of that type.
but is this really the underlying concept?
Does the
* The new behavior maintains consistency between and , so that
specifiers that “look” the same act the same, maintaining consistency
between them.
* I think that having the and behavior vary is a *worse* confusion,
and I believe that the behavior of is far better than previous.
I'm not
The other way in which this makes a whole lot more sense is when
considering projects that use dates as versions. Let's take for
example projects that have a released versions like
2013.08.10
2013.10.30
2013.12.03
2014.02.16
2014.09.23
If I say I want foo 2013, I expect anything in the 2014.*.*
On Mon, Dec 22, 2014 at 2:38 PM, Marcus Smith qwc...@gmail.com wrote:
there's a big difference between stating the concept directly/simply in the
PEP vs readers/users having to reverse engineer it from prefix based
version exclusion clause !=
V.* .
If this is what it's about, users need to
By the way, note that 1.7 doesn't *always* mean 1.7.*
right, got it
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
In particular, , , ~=, and, when using a .*, the != and == use the
number of dots in the given specifier to indicate the precision of the
specifier.
the PEP text is pretty clear on the precision concept for ~= and when using
.*, but not so much for and .
how about an example right there in
23 matches
Mail list logo
