[Distutils] distribute-0.6.35 fails on python 3.3?
Hi All, Can anyone else reproduce this? I have a Python 3.3 virtualenv and I wanted to upgrade one of the packages as follows: $ bin/pip install -U manuel Requirement already up-to-date: manuel in ./lib/python3.3/site-packages Downloading/unpacking distribute from http://pypi.python.org/packages/source/d/distribute/distribute-0.6.35.tar.gz#md5=e55298c7e3a233df1a47a4881a0c9800 (from manuel) Downloading distribute-0.6.35.tar.gz (644kB): 644kB downloaded Running setup.py egg_info for package distribute Traceback (most recent call last): File string, line 3, in module File ./setuptools/__init__.py, line 2, in module from setuptools.extension import Extension, Library File ./setuptools/extension.py, line 5, in module from setuptools.dist import _get_unpatched File ./setuptools/dist.py, line 103 except ValueError, e: ^ SyntaxError: invalid syntax Complete output from command python setup.py egg_info: Traceback (most recent call last): File string, line 3, in module File ./setuptools/__init__.py, line 2, in module from setuptools.extension import Extension, Library File ./setuptools/extension.py, line 5, in module from setuptools.dist import _get_unpatched File ./setuptools/dist.py, line 103 except ValueError, e: ^ SyntaxError: invalid syntax Can other people reproduce this? When was that Python 3 incompatible except clause introduced? cheers. Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distribute-0.6.35 fails on python 3.3?
On Tue, Feb 26, 2013 at 9:21 AM, Chris Withers ch...@simplistix.co.ukwrote: File ./setuptools/dist.py, line 103 except ValueError, e: ^ SyntaxError: invalid syntax Can other people reproduce this? When was that Python 3 incompatible except clause introduced? hg blame setuptools/dist.py -- anatoly t. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [venv] distribute-0.6.35 fails on python 3.3?
On 26 February 2013 06:21, Chris Withers ch...@simplistix.co.uk wrote: File ./setuptools/extension.py, line 5, in module from setuptools.dist import _get_unpatched File ./setuptools/dist.py, line 103 except ValueError, e: ^ SyntaxError: invalid syntax Can other people reproduce this? When was that Python 3 incompatible except clause introduced? I quite often see this, it's usually because something that pip is doing (building the metadata/dependency stuff, the actual code build is fine) is failing to run 2to3. I can't offer anything in the way of a fix, I'm afraid... Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [venv] distribute-0.6.35 fails on python 3.3?
On Tue, Feb 26, 2013 at 09:17:29AM +, Paul Moore wrote: On 26 February 2013 06:21, Chris Withers ch...@simplistix.co.uk wrote: File ./setuptools/dist.py, line 103 except ValueError, e: ^ SyntaxError: invalid syntax Can other people reproduce this? When was that Python 3 incompatible except clause introduced? I quite often see this, it's usually because something that pip is doing (building the metadata/dependency stuff, the actual code build is fine) is failing to run 2to3. I can't offer anything in the way of a fix, I'm afraid... How hard would it be to rewrite distribute to use a common language subset instead of relying on 2to3? Marius Gedminas -- C++ is a loaded machine gun helpfully pointed at your feet with the safety off. -- ChaosDiscord on Slashdot signature.asc Description: Digital signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On 26 February 2013 03:22, Nick Coghlan ncogh...@gmail.com wrote: On Tue, Feb 26, 2013 at 11:06 AM, Donald Stufft donald.stu...@gmail.com wrote: !=1.3 allowing 1.3.1 makes sense to me. 1.3 is equivalent to 1.3.0, 1.3.1 != 1.3.0. Nope, the PEP explicitly disclaims the historical equivalence between 1.3 and 1.3.0. It has to, because they're very different when it comes to what the PEP now calls a compatible release clause (http://www.python.org/dev/peps/pep-0426/#compatible-release), Ruby gems call a pessimistic version constraint (http://docs.rubygems.org/read/chapter/16#page74), PHP composer calls next significant release (http://getcomposer.org/doc/01-basic-usage.md#package-versions) and Node.js npm calls Tilde version range (https://npmjs.org/doc/json.html) (Note: I also checked CPAN version ordering to see if it had an equivalent operation, but Perl's approach appears to be closer to the way pkg_resources handles ordering: http://search.cpan.org/~jpeacock/version-0.9901/lib/version.pod#How_to_compare_version_objects ) However, while numeric maintenance releases are part of the problem here, the real issue is correctly handling *post* releases. Does == 1.3 allow 1.3.post1? Does != 1.3 allow 1.3.post1? Both? Neither? If you use strict string matching for == and !=, then != 1.3 will allow 1.3.post1, which is utterly insane given the PEP's recommended usage of post releases solely for non-functional changes like tweaking the release notes or project metadata. Leaving == as strict and making != prefix based breaks the fundamental relationship between equality and inequality checks, so that's also not a reasonable option. That leaves making both == and != prefix based as the most reasonable alternative, as != 1.3 will then correctly reject 1.3.post1 and the appropriate logical relationship is maintained between the two operators. However, you then need a way to spell an *exact* version request (for use with tools like zc.buildout and pip freeze that are designed to snapshot an application configuration rather than for dependency publication in an index). The current tools are strict with regards to equality - and in dependency pinning I would see it as *surprising* that specifying ==1.3 installs some version that isn't precisely 1.3. Having == mean approximately-equal, instead of the-same-as, seems like a mistake to me. Michael My plan for that use case is to allow is as a comparison operator that means exactly what it says: the version required is precisely the specified version, with no prefix matching or release compatibility assessments allowed. That gives a natural progression in dependency constraints from more permissive to less permissive: Compatible version: some-dist (X.Y) # roughly equivalent to (= X.Y, X+1.dev0) Version equality: some-dist (== X.Y) # roughly equivalent to (= X.Y, X.Y+1.dev0) Version identity: some-dist (is X.Y) # must be exactly X.Y All three clauses also have clearly defined use cases: 1. Use compatible version clauses in published metadata for stable dependencies with a good backwards compatibility policy 2. Use version equality clauses in published metadata for dependencies without a good backwards compatibility policy 3. Use version identity clauses for application and deployment dependency snapshots Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Tuesday, February 26, 2013 at 7:08 AM, Michael Foord wrote: On 26 February 2013 03:22, Nick Coghlan ncogh...@gmail.com (mailto:ncogh...@gmail.com) wrote: On Tue, Feb 26, 2013 at 11:06 AM, Donald Stufft donald.stu...@gmail.com (mailto:donald.stu...@gmail.com) wrote: !=1.3 allowing 1.3.1 makes sense to me. 1.3 is equivalent to 1.3.0, 1.3.1 != 1.3.0. Nope, the PEP explicitly disclaims the historical equivalence between 1.3 and 1.3.0. It has to, because they're very different when it comes to what the PEP now calls a compatible release clause (http://www.python.org/dev/peps/pep-0426/#compatible-release), Ruby gems call a pessimistic version constraint (http://docs.rubygems.org/read/chapter/16#page74), PHP composer calls next significant release (http://getcomposer.org/doc/01-basic-usage.md#package-versions) and Node.js npm calls Tilde version range (https://npmjs.org/doc/json.html) (Note: I also checked CPAN version ordering to see if it had an equivalent operation, but Perl's approach appears to be closer to the way pkg_resources handles ordering: http://search.cpan.org/~jpeacock/version-0.9901/lib/version.pod#How_to_compare_version_objects) However, while numeric maintenance releases are part of the problem here, the real issue is correctly handling *post* releases. Does == 1.3 allow 1.3.post1? Does != 1.3 allow 1.3.post1? Both? Neither? If you use strict string matching for == and !=, then != 1.3 will allow 1.3.post1, which is utterly insane given the PEP's recommended usage of post releases solely for non-functional changes like tweaking the release notes or project metadata. Leaving == as strict and making != prefix based breaks the fundamental relationship between equality and inequality checks, so that's also not a reasonable option. That leaves making both == and != prefix based as the most reasonable alternative, as != 1.3 will then correctly reject 1.3.post1 and the appropriate logical relationship is maintained between the two operators. However, you then need a way to spell an *exact* version request (for use with tools like zc.buildout and pip freeze that are designed to snapshot an application configuration rather than for dependency publication in an index). The current tools are strict with regards to equality - and in dependency pinning I would see it as *surprising* that specifying ==1.3 installs some version that isn't precisely 1.3. Having == mean approximately-equal, instead of the-same-as, seems like a mistake to me. Michael I agree with this, == should mean EXACTLY 1.3, != should mean EXACTLY NOT 1.3. However because these aren't strings and are versions we can understand that: 1.3 == 1.3.0 == 1.3.0.0 == 1.3.0.0.0 etc etc. My plan for that use case is to allow is as a comparison operator that means exactly what it says: the version required is precisely the specified version, with no prefix matching or release compatibility assessments allowed. That gives a natural progression in dependency constraints from more permissive to less permissive: Compatible version: some-dist (X.Y) # roughly equivalent to (= X.Y, X+1.dev0) Version equality: some-dist (== X.Y) # roughly equivalent to (= X.Y, X.Y+1.dev0) Version identity: some-dist (is X.Y) # must be exactly X.Y All three clauses also have clearly defined use cases: 1. Use compatible version clauses in published metadata for stable dependencies with a good backwards compatibility policy 2. Use version equality clauses in published metadata for dependencies without a good backwards compatibility policy 3. Use version identity clauses for application and deployment dependency snapshots Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com (mailto:ncogh...@gmail.com) | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org (mailto:Distutils-SIG@python.org) http://mail.python.org/mailman/listinfo/distutils-sig -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Tue, Feb 26, 2013 at 10:08 PM, Michael Foord fuzzy...@gmail.com wrote: The current tools are strict with regards to equality - and in dependency pinning I would see it as *surprising* that specifying ==1.3 installs some version that isn't precisely 1.3. Having == mean approximately-equal, instead of the-same-as, seems like a mistake to me. The most palatable alternative I've seen so far is for a trailing .* to trigger prefix matching for == and != (it would be disallowed for anything else). It's *slightly* odd, because the . is implied rather than explicit for alphas, betas and release candidates (a choice driven by the weight of existing practice on PyPI, as well as CPython's own conventions), but it's probably still a better idea than trying to change the meaning of ==. I *don't* like the idea of (== 1.3) and (== 1.3.0) being equivalent when (1.3) and (1.3.0) are substantially different, though. Instead, I'll reinstate a variant of the commentary from PEP 386 that pointed out the value of always publishing releases with a consistent number of components by including the trailing .0. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Tuesday, February 26, 2013 at 8:17 AM, Nick Coghlan wrote: I *don't* like the idea of (== 1.3) and (== 1.3.0) being equivalent when (1.3) and (1.3.0) are substantially different, though. Instead, I'll reinstate a variant of the commentary from PEP 386 that pointed out the value of always publishing releases with a consistent number of components by including the trailing .0. I think it makes absolute sense. These aren't strings they are version numbers. 1.0 == 1.00 == 1.00 == 1.000, adding more zeros doesn't change the semantics. It also matches the existing practices of setuptools. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Tue, Feb 26, 2013 at 8:17 AM, Nick Coghlan ncogh...@gmail.com wrote: On Tue, Feb 26, 2013 at 10:08 PM, Michael Foord fuzzy...@gmail.com wrote: The current tools are strict with regards to equality - and in dependency pinning I would see it as *surprising* that specifying ==1.3 installs some version that isn't precisely 1.3. Having == mean approximately-equal, instead of the-same-as, seems like a mistake to me. The most palatable alternative I've seen so far is for a trailing .* to trigger prefix matching for == and != (it would be disallowed for anything else). It's *slightly* odd, because the . is implied rather than explicit for alphas, betas and release candidates (a choice driven by the weight of existing practice on PyPI, as well as CPython's own conventions), but it's probably still a better idea than trying to change the meaning of ==. I *don't* like the idea of (== 1.3) and (== 1.3.0) being equivalent when (1.3) and (1.3.0) are substantially different, though. Instead, I'll reinstate a variant of the commentary from PEP 386 that pointed out the value of always publishing releases with a consistent number of components by including the trailing .0. 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. 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. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Tue, Feb 26, 2013 at 5:23 AM, Donald Stufft donald.stu...@gmail.com wrote: On Tuesday, February 26, 2013 at 8:17 AM, Nick Coghlan wrote: I *don't* like the idea of (== 1.3) and (== 1.3.0) being equivalent when (1.3) and (1.3.0) are substantially different, though. Instead, I'll reinstate a variant of the commentary from PEP 386 that pointed out the value of always publishing releases with a consistent number of components by including the trailing .0. I think it makes absolute sense. These aren't strings they are version numbers. 1.0 == 1.00 == 1.00 == 1.000, adding more zeros doesn't change the semantics. In numeric contexts, the semantics do change. There is a notion of precision or significant digits. For example, 1.04 can be expressed by 1.0 but not by 1.00. --Chris ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Tue, Feb 26, 2013 at 11:23 PM, Donald Stufft donald.stu...@gmail.com wrote: On Tuesday, February 26, 2013 at 8:17 AM, Nick Coghlan wrote: I *don't* like the idea of (== 1.3) and (== 1.3.0) being equivalent when (1.3) and (1.3.0) are substantially different, though. Instead, I'll reinstate a variant of the commentary from PEP 386 that pointed out the value of always publishing releases with a consistent number of components by including the trailing .0. I think it makes absolute sense. These aren't strings they are version numbers. 1.0 == 1.00 == 1.00 == 1.000, adding more zeros doesn't change the semantics. The number of components matters, precisely in the significant digits sense that Chris mentions. In a compatible release clause, 1.3 is a declaration of compatibility with everything less than 2.0, whereas 1.3.0 limits the compatibility to versions less than 1.4.0 If 1.3 and 1.3.0 mean different things in that context (as they should), I'm *not* going to approve a standard that makes them the same when you stick an == sign in front of them. Remember, part of the goals of both PEP 386 and PEP 426 is to tighten up cases where setuptools is considered too permissive, because it's guessing in the face of ambiguity. Trailing zeroes should be considered implied when comparing versions is one such guess. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Tuesday, February 26, 2013 at 10:10 AM, Nick Coghlan wrote: Remember, part of the goals of both PEP 386 and PEP 426 is to tighten up cases where setuptools is considered too permissive, because it's guessing in the face of ambiguity. Trailing zeroes should be considered implied when comparing versions is one such guess. It goes against the common usage in the Python community. * 135869 total releases * 66528 total releases that have at least 3 version levels (A.B.C) * 20244 total releases that have at least 3 version levels where A.B and A.B.0 appear to be equivalent[1]. * 86 total releases using at least 3 version levels where A.B and A.B.0 appear to be different[2]. Would break the assumptions made in ~30% of the releases using at least 3 version levels, or 15% of all releases. Furthermore A.B == A.B.0 being equivalent is a matter of opinion with no clear answer. I would be inclined to say that not breaking it for the 15% of all releases is a greater net benefit here then anyones notion of right unless there is a clear benefit. For what it's worth, the implementation of PEP386 treats them as equal as well, choosing to pad the shorter one out to whatever the requisite number of 0's is required to make the number of components equal. On a tangential note PyPI should probably not be allowing you to upload both a A.B and an A.B.0, or at the very least if we want PyPI to continue allowing it then we need to be explicit about how that should be handled in either scheme. [1] Determined by looking for A.B.N.NUMERIC_BUT_NOT_ZERO, and then seeing if there was a A.B.N without a A.B.N.0. [2] Determined the same as in [1], but dropping the without a A.B.N.0 and differences the counts. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Tue, Feb 26, 2013 at 11:01 AM, Donald Stufft donald.stu...@gmail.comwrote: On Tuesday, February 26, 2013 at 10:10 AM, Nick Coghlan wrote: Remember, part of the goals of both PEP 386 and PEP 426 is to tighten up cases where setuptools is considered too permissive, because it's guessing in the face of ambiguity. Trailing zeroes should be considered implied when comparing versions is one such guess. It goes against the common usage in the Python community. * 135869 total releases * 66528 total releases that have at least 3 version levels (A.B.C) * 20244 total releases that have at least 3 version levels where A.B and A.B.0 appear to be equivalent[1]. * 86 total releases using at least 3 version levels where A.B and A.B.0 appear to be different[2]. Would break the assumptions made in ~30% of the releases using at least 3 version levels, or 15% of all releases. Furthermore A.B == A.B.0 being equivalent is a matter of opinion with no clear answer. I would be inclined to say that not breaking it for the 15% of all releases is a greater net benefit here then anyones notion of right unless there is a clear benefit. For what it's worth, the implementation of PEP386 treats them as equal as well, choosing to pad the shorter one out to whatever the requisite number of 0's is required to make the number of components equal. On a tangential note PyPI should probably not be allowing you to upload both a A.B and an A.B.0, or at the very least if we want PyPI to continue allowing it then we need to be explicit about how that should be handled in either scheme. With prefix equals would the following evaluate to true? 1.4 == 1 == 1.3.1 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Tuesday, February 26, 2013 at 11:07 AM, Daniel Holth wrote: On Tue, Feb 26, 2013 at 11:01 AM, Donald Stufft donald.stu...@gmail.com (mailto:donald.stu...@gmail.com) wrote: On Tuesday, February 26, 2013 at 10:10 AM, Nick Coghlan wrote: Remember, part of the goals of both PEP 386 and PEP 426 is to tighten up cases where setuptools is considered too permissive, because it's guessing in the face of ambiguity. Trailing zeroes should be considered implied when comparing versions is one such guess. It goes against the common usage in the Python community. * 135869 total releases * 66528 total releases that have at least 3 version levels (A.B.C) * 20244 total releases that have at least 3 version levels where A.B and A.B.0 appear to be equivalent[1]. * 86 total releases using at least 3 version levels where A.B and A.B.0 appear to be different[2]. Would break the assumptions made in ~30% of the releases using at least 3 version levels, or 15% of all releases. Furthermore A.B == A.B.0 being equivalent is a matter of opinion with no clear answer. I would be inclined to say that not breaking it for the 15% of all releases is a greater net benefit here then anyones notion of right unless there is a clear benefit. For what it's worth, the implementation of PEP386 treats them as equal as well, choosing to pad the shorter one out to whatever the requisite number of 0's is required to make the number of components equal. On a tangential note PyPI should probably not be allowing you to upload both a A.B and an A.B.0, or at the very least if we want PyPI to continue allowing it then we need to be explicit about how that should be handled in either scheme. With prefix equals would the following evaluate to true? 1.4 == 1 == 1.3.1 Not sure if you meant to direct that to me, but with what I'm proposing (e.g. the existing) then no. That would expand out to be: 1.4.0 == 1.0.0 == 1.3.1 which would be false.___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Wed, Feb 27, 2013 at 2:07 AM, Daniel Holth dho...@gmail.com wrote: With prefix equals would the following evaluate to true? 1.4 == 1 == 1.3.1 I guess that's the other advantage of the wildcard notation - it makes it very clear something special is going on :) For the .0 expansion, I like Donald's explanation that when two numbers with an uneven number of components are compared with == or !=, the shorter one is expanded with .0 elements until they have the same number. That gives the following comparison clauses: Compatible version: some-dist (X.Y) # Expects (= X.Y, X+1.dev0) Wildcard version: some-dist (== X.Y.*) # Expects (= X.Y, X.Y+1.dev0) Exact version: some-dist (== X.Y) # Expects X.Y, allows extra .0 suffixes I can live with that. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [venv] distribute-0.6.35 fails on python 3.3?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/26/2013 04:20 AM, Marius Gedminas wrote: On Tue, Feb 26, 2013 at 09:17:29AM +, Paul Moore wrote: On 26 February 2013 06:21, Chris Withers ch...@simplistix.co.uk wrote: File ./setuptools/dist.py, line 103 except ValueError, e: ^ SyntaxError: invalid syntax Can other people reproduce this? When was that Python 3 incompatible except clause introduced? I quite often see this, it's usually because something that pip is doing (building the metadata/dependency stuff, the actual code build is fine) is failing to run 2to3. I can't offer anything in the way of a fix, I'm afraid... How hard would it be to rewrite distribute to use a common language subset instead of relying on 2to3? The sheer number of developer hours saved by not waiting for the 2to3 run every time a Py3k virtualenv is created should dwarf whatever effort is involve. Any volunteers to take on for the team? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEs/CAACgkQ+gerLs4ltQ6oEgCcDobQyI2TbW5Ev0NDtxAOqSlJ GBwAn3F4NMJ9nzY1/xmkxcvJdW8hceYp =Bbmr -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [venv] distribute-0.6.35 fails on python 3.3?
Tres Seaver tseaver at palladion.com writes: How hard would it be to rewrite distribute to use a common language subset instead of relying on 2to3? I did this months ago, when doing PEP 405 venv development was getting old fast because of the 2to3 delay: https://bitbucket.org/vinay.sajip/distribute3 It's been mentioned on this list, but none of the distribute maintainers appear to have picked up on it. It's been a short while (10 Jan 2013) since I synchronised with the main repo, but it typically doesn't take all that long to do. All the tests pass whenever I merge upstream changes, but I'm not sure how much confidence the maintainers have about test coverage and whether all tests passing means enough for them to release into the wild. Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [venv] distribute-0.6.35 fails on python 3.3?
All the tests pass whenever I merge upstream changes, but I'm not sure how much confidence the maintainers have about test coverage and whether all tests passing means enough for them to release into the wild. if they did release it to the wild, then the decision get's passed to virtualenv, as to when it feels comfortable including the upgrade. virtualenv/pip end's up being how many user's will first encounter distribute releases (and problems if there are any). running the pip test suite against distribute RCs before releasing would be a good idea. I'm happy to work with distribute people to make that happen. Marcus ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Tue, Feb 26, 2013 at 8:01 AM, Donald Stufft donald.stu...@gmail.com wrote: On Tuesday, February 26, 2013 at 10:10 AM, Nick Coghlan wrote: Remember, part of the goals of both PEP 386 and PEP 426 is to tighten up cases where setuptools is considered too permissive, because it's guessing in the face of ambiguity. Trailing zeroes should be considered implied when comparing versions is one such guess. It goes against the common usage in the Python community. * 135869 total releases * 66528 total releases that have at least 3 version levels (A.B.C) * 20244 total releases that have at least 3 version levels where A.B and A.B.0 appear to be equivalent[1]. * 86 total releases using at least 3 version levels where A.B and A.B.0 appear to be different[2]. Would break the assumptions made in ~30% of the releases using at least 3 version levels, or 15% of all releases. Furthermore A.B == A.B.0 being equivalent is a matter of opinion with no clear answer. I would be inclined to say that not breaking it for the 15% of all releases is a greater net benefit here then anyones notion of right unless there is a clear benefit. For what it's worth, the implementation of PEP386 treats them as equal as well, choosing to pad the shorter one out to whatever the requisite number of 0's is required to make the number of components equal. On a tangential note PyPI should probably not be allowing you to upload both a A.B and an A.B.0, or at the very least if we want PyPI to continue allowing it then we need to be explicit about how that should be handled in either scheme. There is a similar issue with leading zeroes. For example, I was able to upload to PyPI versions both of the form A.B.2 and A.B.02. The PEP should probably be explicit and state that any N must be the unique integer representation, and state how that case should be handled if violated (with respect to equality, etc). Is it easy to check if any releases on PyPI have versions with leading zeroes? --Chris ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Tue, Feb 26, 2013 at 2:53 PM, Chris Jerdonek chris.jerdo...@gmail.com wrote: On Tue, Feb 26, 2013 at 8:01 AM, Donald Stufft donald.stu...@gmail.com wrote: On Tuesday, February 26, 2013 at 10:10 AM, Nick Coghlan wrote: Remember, part of the goals of both PEP 386 and PEP 426 is to tighten up cases where setuptools is considered too permissive, because it's guessing in the face of ambiguity. Trailing zeroes should be considered implied when comparing versions is one such guess. It goes against the common usage in the Python community. * 135869 total releases * 66528 total releases that have at least 3 version levels (A.B.C) * 20244 total releases that have at least 3 version levels where A.B and A.B.0 appear to be equivalent[1]. * 86 total releases using at least 3 version levels where A.B and A.B.0 appear to be different[2]. Would break the assumptions made in ~30% of the releases using at least 3 version levels, or 15% of all releases. Furthermore A.B == A.B.0 being equivalent is a matter of opinion with no clear answer. I would be inclined to say that not breaking it for the 15% of all releases is a greater net benefit here then anyones notion of right unless there is a clear benefit. For what it's worth, the implementation of PEP386 treats them as equal as well, choosing to pad the shorter one out to whatever the requisite number of 0's is required to make the number of components equal. On a tangential note PyPI should probably not be allowing you to upload both a A.B and an A.B.0, or at the very least if we want PyPI to continue allowing it then we need to be explicit about how that should be handled in either scheme. There is a similar issue with leading zeroes. For example, I was able to upload to PyPI versions both of the form A.B.2 and A.B.02. The PEP should probably be explicit and state that any N must be the unique integer representation, and state how that case should be handled if violated (with respect to equality, etc). Is it easy to check if any releases on PyPI have versions with leading zeroes? --Chris We could use an official PyPI normalization for both dist names and versions. PyPI reportedly at least prohibits dists that differ only in case. PEP 427 converts anything that is not a letter or a digit or . into _, extending the setuptools scheme by allowing Unicode letters and digits. Unfortunately this is unkind to my favorite dist https://crate.io/packages/%E2%98%83/ which Donald still hasn't written any code for. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [venv] distribute-0.6.35 fails on python 3.3?
most of the pip tests default to using virtualenv with Setuptools, but there are enough that use Distribute to smoke out issues. most of the 2.x tests that is. all the 3.x tests end up using distribute. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [venv] distribute-0.6.35 fails on python 3.3?
running the pip test suite against distribute RCs before releasing would be a good idea. I'm happy to work with distribute people to make that happen. granted, it's somewhat awkward, but I did this recently, before upgrading distribute-0.6.34 into virtualenv. it involves running pip's tests using a modified .travis.yml file that installs virtualenv from a git branch that has the distribute upgrade to be tested. I did this due to previous experience in watching a distribute upgrade start failing pip tests, and having to go back and get a distribute patch, and re-release virtualenv. most of the pip tests default to using virtualenv with Setuptools, but there are enough that use Distribute to smoke out issues. Marcus ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Tuesday, February 26, 2013 at 2:53 PM, Chris Jerdonek wrote: On Tue, Feb 26, 2013 at 8:01 AM, Donald Stufft donald.stu...@gmail.com (mailto:donald.stu...@gmail.com) wrote: On Tuesday, February 26, 2013 at 10:10 AM, Nick Coghlan wrote: Remember, part of the goals of both PEP 386 and PEP 426 is to tighten up cases where setuptools is considered too permissive, because it's guessing in the face of ambiguity. Trailing zeroes should be considered implied when comparing versions is one such guess. It goes against the common usage in the Python community. * 135869 total releases * 66528 total releases that have at least 3 version levels (A.B.C) * 20244 total releases that have at least 3 version levels where A.B and A.B.0 appear to be equivalent[1]. * 86 total releases using at least 3 version levels where A.B and A.B.0 appear to be different[2]. Would break the assumptions made in ~30% of the releases using at least 3 version levels, or 15% of all releases. Furthermore A.B == A.B.0 being equivalent is a matter of opinion with no clear answer. I would be inclined to say that not breaking it for the 15% of all releases is a greater net benefit here then anyones notion of right unless there is a clear benefit. For what it's worth, the implementation of PEP386 treats them as equal as well, choosing to pad the shorter one out to whatever the requisite number of 0's is required to make the number of components equal. On a tangential note PyPI should probably not be allowing you to upload both a A.B and an A.B.0, or at the very least if we want PyPI to continue allowing it then we need to be explicit about how that should be handled in either scheme. There is a similar issue with leading zeroes. For example, I was able to upload to PyPI versions both of the form A.B.2 and A.B.02. The PEP should probably be explicit and state that any N must be the unique integer representation, and state how that case should be handled if violated (with respect to equality, etc). Is it easy to check if any releases on PyPI have versions with leading zeroes? --Chris I can check it pretty easily since I have a copy of all the PyPI releases in postgresql locally. Will look shortly and see. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Tuesday, February 26, 2013 at 2:53 PM, Chris Jerdonek wrote: On Tue, Feb 26, 2013 at 8:01 AM, Donald Stufft donald.stu...@gmail.com (mailto:donald.stu...@gmail.com) wrote: On Tuesday, February 26, 2013 at 10:10 AM, Nick Coghlan wrote: Remember, part of the goals of both PEP 386 and PEP 426 is to tighten up cases where setuptools is considered too permissive, because it's guessing in the face of ambiguity. Trailing zeroes should be considered implied when comparing versions is one such guess. It goes against the common usage in the Python community. * 135869 total releases * 66528 total releases that have at least 3 version levels (A.B.C) * 20244 total releases that have at least 3 version levels where A.B and A.B.0 appear to be equivalent[1]. * 86 total releases using at least 3 version levels where A.B and A.B.0 appear to be different[2]. Would break the assumptions made in ~30% of the releases using at least 3 version levels, or 15% of all releases. Furthermore A.B == A.B.0 being equivalent is a matter of opinion with no clear answer. I would be inclined to say that not breaking it for the 15% of all releases is a greater net benefit here then anyones notion of right unless there is a clear benefit. For what it's worth, the implementation of PEP386 treats them as equal as well, choosing to pad the shorter one out to whatever the requisite number of 0's is required to make the number of components equal. On a tangential note PyPI should probably not be allowing you to upload both a A.B and an A.B.0, or at the very least if we want PyPI to continue allowing it then we need to be explicit about how that should be handled in either scheme. There is a similar issue with leading zeroes. For example, I was able to upload to PyPI versions both of the form A.B.2 and A.B.02. The PEP should probably be explicit and state that any N must be the unique integer representation, and state how that case should be handled if violated (with respect to equality, etc). Is it easy to check if any releases on PyPI have versions with leading zeroes? In [45]: l = [x for x in releases if any([y for y in x[1].split(.) if y.startswith(0) and y.isdigit() and not y.endswith(0)])] In [46]: len(l) Out[46]: 1162 Note this doesn't check if they have confusing versions, (e.g. 1.1 and 1.01) just if they have a segment with a leading 0. --Chris ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Tue, Feb 26, 2013 at 2:08 PM, Donald Stufft donald.stu...@gmail.com wrote: In [45]: l = [x for x in releases if any([y for y in x[1].split(.) if y.startswith(0) and y.isdigit() and not y.endswith(0)])] In [46]: len(l) Out[46]: 1162 Note this doesn't check if they have confusing versions, (e.g. 1.1 and 1.01) just if they have a segment with a leading 0. Thanks. Probably not worth doing again, but should the last part be y != 0 to include cases like 010 and 00? --Chris ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Tuesday, February 26, 2013 at 7:06 PM, Chris Jerdonek wrote: On Tue, Feb 26, 2013 at 2:08 PM, Donald Stufft donald.stu...@gmail.com (mailto:donald.stu...@gmail.com) wrote: In [45]: l = [x for x in releases if any([y for y in x[1].split(.) if y.startswith(0) and y.isdigit() and not y.endswith(0)])] In [46]: len(l) Out[46]: 1162 Note this doesn't check if they have confusing versions, (e.g. 1.1 and 1.01) just if they have a segment with a leading 0. Thanks. Probably not worth doing again, but should the last part be y != 0 to include cases like 010 and 00? --Chris I happened to still have that console open, In [49]: len([x for x in releases if any([y for y in x[1].split(.) if y.startswith(0) and y.isdigit() and y != 0])]) Out[49]: 1236 In [52]: len([x for x in releases if any([y for y in x[1].split(.) if y.startswith(0) and y.isdigit() and int(y) != 0])]) Out[52]: 1177 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
