[Distutils] setuptools-8.4.zip?
Bootstrapping buildout is failing because buildout uses https://bootstrap.pypa.io/ez_setup.py which tried to download: https://pypi.python.org/packages/source/s/setuptools/setuptools-8.4.zip which doesn't exist. Did someone forget to upload setuptools-8.4.zip? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setuptools-8.4.zip?
Jim Fulton jim at zope.com writes: Did someone forget to upload setuptools-8.4.zip? Jim I don't really understand how it came about, but the sever was on the wrong branch or something. Benjamin Peterson whacked it with a stick and now it should be good. Alex ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setuptools-8.4.zip?
On Sat, Dec 27, 2014 at 1:47 PM, Alex Gaynor alex.gay...@gmail.com wrote: Jim Fulton jim at zope.com writes: Did someone forget to upload setuptools-8.4.zip? Jim I don't really understand how it came about, but the sever was on the wrong branch or something. Benjamin Peterson whacked it with a stick and now it should be good. Thanks. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440: foo-X.Y.Z does not satisfy fooX.Y?
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) above), you
are supposed to compare the
candidate version 1.7.dev1 with the specified version 1.7.
yes, I agree with you. : )
my 2 examples weren't meant to exemplify the inconsistency I was referring
to.
they were intended to be response to you quoting the bit about implicitly
excluded
Because the 2nd example was True, they're not implicitly excluded.
For fear that my current point is lost now (since it's changed from the
original title), I'm going to start a new thread that sums it up real
brief...
Marcus
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] PEP440: 1.7 vs =1.7
I'm starting a new thread to state cleanly what my current question/concern is... per PEP440 as I understand it: - for 1.7, 1.7 means roughly the 1.7 series or 1.7* - for =1.7, 1.7 means literally 1.7 (with zero-padding as needed) While I understand the motivation for the series conception of 1.7 to deal with prereleases, the resulting inconsistency in meaning for 1.7 is what concerns me. It's odd . Can someone make it not seem odd for 1.7 to change meanings just because you switch between = and ? And for anyone who wants to say that 1.7 also means the 1.7 series for =, note that 1.7 prereleases do not satisfy =1.7 Would a solution be to make = also use the series concept?, i.e. make pre-releases satisfy =1.7 Marcus ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440: 1.7 vs =1.7
On Dec 27, 2014, at 8:35 PM, Marcus Smith qwc...@gmail.com wrote: I'm starting a new thread to state cleanly what my current question/concern is... per PEP440 as I understand it: - for 1.7, 1.7 means roughly the 1.7 series or 1.7* - for =1.7, 1.7 means literally 1.7 (with zero-padding as needed) While I understand the motivation for the series conception of 1.7 to deal with prereleases, the resulting inconsistency in meaning for 1.7 is what concerns me. It's odd . Can someone make it not seem odd for 1.7 to change meanings just because you switch between = and ? And for anyone who wants to say that 1.7 also means the 1.7 series for =, note that 1.7 prereleases do not satisfy =1.7 Would a solution be to make = also use the series concept?, i.e. make pre-releases satisfy =1.7 The equality operator pads zeros, = has the equality operator as part of it. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440: 1.7 vs =1.7
On Sat, Dec 27, 2014 at 7:35 PM, Marcus Smith qwc...@gmail.com wrote: I'm starting a new thread to state cleanly what my current question/concern is... per PEP440 as I understand it: - for 1.7, 1.7 means roughly the 1.7 series or 1.7* You mean 1.7.* right? Because 1.70 would satisfy 1.7 - for =1.7, 1.7 means literally 1.7 (with zero-padding as needed) While I understand the motivation for the series conception of 1.7 to deal with prereleases, the resulting inconsistency in meaning for 1.7 is what concerns me. It's odd . Can someone make it not seem odd for 1.7 to change meanings just because you switch between = and ? And for anyone who wants to say that 1.7 also means the 1.7 series for =, note that 1.7 prereleases do not satisfy =1.7 Would a solution be to make = also use the series concept?, i.e. make pre-releases satisfy =1.7 Marcus ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440: 1.7 vs =1.7
In gives me a minor bit of pause. However any alternative that I can come up with bothers me more, especially since I don't believe many people actually even *use* a bare and any alternative I can come up with has worse behavior for operators which get much more use. what about making =,= also use the series concept? where does that go wrong? ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440: 1.7 vs =1.7
On Dec 27, 2014, at 9:10 PM, Marcus Smith qwc...@gmail.com wrote: In gives me a minor bit of pause. However any alternative that I can come up with bothers me more, especially since I don't believe many people actually even *use* a bare and any alternative I can come up with has worse behavior for operators which get much more use. what about making =,= also use the series concept? where does that go wrong? To be clear, you’re talking about doing something like: 1.7 is 1.7 AND !=1.7.* which would correlate to 1.7 OR ==1.7.*? Honestly, the thing that I dislike about that is it takes a behavior which is less intuitive (I do agree that the behavior of is less intuitive) and applies to globally. I don't think people would expect =1.7 to match 1.7.dev0 and given that I don't think people would expect =1.7.0 to _not_match 1.7.dev0. I totally agree that the behavior of isn't the greatest, I don't think the solution to that problem is to globally apply that particular wart. The only *reasonable* solutions I can think of are: 1. Make and both act as simple comparison operators, and have 1.7 and 1.7.0 both allow 1.7.1. This would include also allowing 1.7.dev0 to be 1.7 and 1.7.0. 2. Make and both act as exclusive comparison operators, and which is the current behavior. 3. Make and both act as simple comparison operators, but include a special case that does not ever match pre-releases of the version mentioned in the specifier. So 3 would not match a pre-released like 3.dev0, and 3.1 would not match a pre-release like 3.1.dev0 but would match a pre-release like 3.0.dev0. It may be that the correct solution is to just treat pre-releases as special and just switch to 3. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Detecting rst errors when uploading to pypi
Hey, I'm trying to get my README to render properly on pypi but I haven't found a way to detect the errors pypi is experiencing. The package I'm trying to upload is here: https://pypi.python.org/pypi/pyramid_celery I've checked the README.rst with restview, rst2html, and collective.showdocs and they all render the RST just fine. It seems like I'm not the only one having this issue: https://bitbucket.org/pypa/pypi/issue/161/rest-formatting-fails-and-there-is-no-way So what is the recommended route for debugging the problem? I would really like to fix it but without know the problem I would just to make random guesses. Thanks, John ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440: 1.7 vs =1.7
On Dec 27, 2014, at 9:26 PM, Donald Stufft don...@stufft.io wrote: On Dec 27, 2014, at 9:10 PM, Marcus Smith qwc...@gmail.com mailto:qwc...@gmail.com wrote: In gives me a minor bit of pause. However any alternative that I can come up with bothers me more, especially since I don't believe many people actually even *use* a bare and any alternative I can come up with has worse behavior for operators which get much more use. what about making =,= also use the series concept? where does that go wrong? To be clear, you’re talking about doing something like: 1.7 is 1.7 AND !=1.7.* which would correlate to 1.7 OR ==1.7.*? Honestly, the thing that I dislike about that is it takes a behavior which is less intuitive (I do agree that the behavior of is less intuitive) and applies to globally. I don't think people would expect =1.7 to match 1.7.dev0 and given that I don't think people would expect =1.7.0 to _not_match 1.7.dev0. I totally agree that the behavior of isn't the greatest, I don't think the solution to that problem is to globally apply that particular wart. The only *reasonable* solutions I can think of are: 1. Make and both act as simple comparison operators, and have 1.7 and 1.7.0 both allow 1.7.1. This would include also allowing 1.7.dev0 to be 1.7 and 1.7.0. 2. Make and both act as exclusive comparison operators, and which is the current behavior. 3. Make and both act as simple comparison operators, but include a special case that does not ever match pre-releases of the version mentioned in the specifier. So 3 would not match a pre-released like 3.dev0, and 3.1 would not match a pre-release like 3.1.dev0 but would match a pre-release like 3.0.dev0. It may be that the correct solution is to just treat pre-releases as special and just switch to 3. After thinking about this some more, I made a PR that adjusts the packaging library so that is has semantics which might be better overall than what is currently in PEP 440. This PR is at https://github.com/pypa/packaging/pull/25 if someone wants to play with it at all, but the highlights are: * 1.7.1 matches 1.7 (previously it did not) * 1.7.post1 does not match 1.7 (previously it did not) * 1.7.post1 matches 1.7.post0 (previously it did) * 3.dev0 does not match 3.0 (previously it did) * 3.0.dev0 does not match 3.0 (previously it did not) * 3.0.dev0 matches 3.0rc1 (previously it did) Instead of having V and V impliy !=V.*, this means that: 1. A V does not match a pre-release of V unless V is itself a pre-release. 2. A V does not match a post-release of V unless V is itself a post-release. 3. A V does not match a V+local.version. Implicitly these three rules are also true, but they are true because of the ordered nature of the versions and the mathemtical meaning of and rather than any rule mentioned in the PEP: 4. A V does not match a post-release of V unless V is itself a post-release. 5. A V does not match a pre-release of V unless V is itself a pre-release. 6. A V does not match a V+local.version. If you check out my branch, you can play around with the specifier rules as I've implemented them now by just doing: from packaging.specifiers import SpecifierSet SpecifierSet(1.7).contains(1.7.1, prereleases=True) True SpecifierSet(1.7).contains(1.7.post1, prereleases=True) False SpecifierSet(1.7.post0).contains(1.7.post1, prereleases=True) True SpecifierSet(1.7).contains(1.7+thing.1, prereleases=True) False SpecifierSet(3.0.0).contains(3.0.dev0, prereleases=True) False SpecifierSet(3).contains(3.0.dev0, prereleases=True) False SpecifierSet(3rc1).contains(3.0.dev0, prereleases=True) True Does this better match your expectations? I think I might like these rules better as they handle zero padding similarly to ==, !=, =, and = (sans when == and != have a .*) which means that a rule like 3.0 won't accept 3.dev0 even though the current PEP means that it does. I think it also follows along better with what people expect both for and for . --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
