At 01:14 PM 10/6/2009 -0700, Guido van Rossum wrote:
suggest nobody hold their breath waiting for setuptools 0.7.
I've never suggested or implied otherwise.
But, if you like Distribute so much, why not just add it directly to the stdlib? ;-)
AFAIK, the only reason they've had multiple releases of it is to address the issues with its hijacking of setuptools; in a stdlib version all that stuff could be dropped. Otherwise, it'd already be "mature".
There are many wins to be had from such a move, not the least of which is that it allows something to go into the stdlib that isn't (branding-wise) associated with me or setuptools, and lets it become owned/supported by an even wider community.
Less political bickering, and the some of the technical results I hoped for all along are achieved. Yay, open source.
+1
For a large number of people [1, 2, 3], setuptools is already a critical part of Python. Make it official. Let everyone know that future releases of Python will not break setuptools/Distribute, and that they can rely on backwards-compatibility with the myriad existing packages. Make the next release of the distutils standard lib module be Distribute.
(Perhaps some people will complain, but they can channel their energy into improving the new distutils.)
Regards,
Zooko
[1] The majority of professional developers using Python rely on setuptools to distribute and to use packages: http://tarekziade.wordpress.com/2009/03/26/packaging-survey-first-results/ [2] setuptools is one of the most downloaded packages on PyPI: http://pypi.python.org/pypi/setuptools http://blog.delaguardia.com.mx/tags/pypi [3] about one fifth of Debian users who install python2.5 also install python-pkg-resources: http://qa.debian.org/popcon.php?package=python-setuptools http://qa.debian.org/popcon.php?package=python2.5
On Wed, Oct 07, 2009 at 10:56:49AM -0600, Zooko O'Whielacronx wrote:
For a large number of people [1, 2, 3], setuptools is already a critical part of Python. Make it official. Let everyone know that future releases of Python will not break setuptools/Distribute, and that they can rely on backwards-compatibility
Who will pay the price of maintaining that part of stdlib and the price of compatibility? Because there is always a price; should the core developers be burdened?
Oleg.
Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
Zooko O'Whielacronx wrote:
+1
For a large number of people [1, 2, 3], setuptools is already a critical part of Python. Make it official. Let everyone know that future releases of Python will not break setuptools/Distribute, and that they can rely on backwards-compatibility with the myriad existing packages. Make the next release of the distutils standard lib module be Distribute.
(Perhaps some people will complain, but they can channel their energy into improving the new distutils.)
We've had that discussion in past and a few times. setuptools/Distribute is not distutils, just an add-on (and there are others as well).
There are good concepts in setuptools, but the implementation is just not suitable for stdlib integration.
Hopefully, Distribute can fix the hacks, trim down the number of features to what people really use, add a proper uninstall command and then we can have the add-to-the-stdlib discussion again.
Having more competition will also help, e.g. ActiveState's PyPM looks promising (provided they choose to open-source it) and then there's pip.
Things look promising, indeed.
Regards,
Zooko
[1] The majority of professional developers using Python rely on setuptools to distribute and to use packages: http://tarekziade.wordpress.com/2009/03/26/packaging-survey-first-results/ [2] setuptools is one of the most downloaded packages on PyPI: http://pypi.python.org/pypi/setuptools http://blog.delaguardia.com.mx/tags/pypi [3] about one fifth of Debian users who install python2.5 also install python-pkg-resources: http://qa.debian.org/popcon.php?package=python-setuptools http://qa.debian.org/popcon.php?package=python2.5
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/mal%40egenix.com
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Oct 07 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Wed, Oct 7, 2009 at 7:27 PM, M.-A. Lemburg mal@egenix.com wrote:
Zooko O'Whielacronx wrote:
+1
For a large number of people [1, 2, 3], setuptools is already a critical part of Python. Make it official. Let everyone know that future releases of Python will not break setuptools/Distribute, and that they can rely on backwards-compatibility with the myriad existing packages. Make the next release of the distutils standard lib module be Distribute.
(Perhaps some people will complain, but they can channel their energy into improving the new distutils.)
We've had that discussion in past and a few times. setuptools/Distribute is not distutils, just an add-on (and there are others as well).
There are good concepts in setuptools, but the implementation is just not suitable for stdlib integration.
Hopefully, Distribute can fix the hacks, trim down the number of features to what people really use, add a proper uninstall command and then we can have the add-to-the-stdlib discussion again.
Having more competition will also help, e.g. ActiveState's PyPM looks promising (provided they choose to open-source it) and then there's pip.
Things look promising, indeed.
100% Agreed !
And before considering adding "bits" of Distribute (or Setuptools) in Distutils, we need to finish our work on PEP 376 and PEP 386, and the changes we've planned for PEP 341.
The work we've done there so far in these PEPs is basically trying to have a consensus on the missing standard that is lacking in Distutils, and that was partially solved by Setuptools.
I have good hopes that these PEP will be finished before 2.7 is out.
Notice that PEP 382 (namespaced packages) is already a great step forward. (by the way, I thought this one was accepted, shouldn't its status updated ?)
Tarek
-- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
Thanks for the reply, MAL.
How would we judge whether Distribute is ready for inclusion in the Python standard lib? Maybe if it has a few more releases, leaving a trail of "closed: fixed" issue tickets behind it?
Regards,
Zooko
On Wed, Oct 7, 2009 at 10:37, Zooko O'Whielacronx zookog@gmail.com wrote:
Thanks for the reply, MAL.
How would we judge whether Distribute is ready for inclusion in the Python standard lib? Maybe if it has a few more releases, leaving a trail of "closed: fixed" issue tickets behind it?
When Tarek says it's ready.
-Brett
Zooko O'Whielacronx wrote:
Thanks for the reply, MAL.
How would we judge whether Distribute is ready for inclusion in the Python standard lib? Maybe if it has a few more releases, leaving a trail of "closed: fixed" issue tickets behind it?
I guess it'll just have to take the usual path of new modules/packages for the stdlib...
http://www.python.org/dev/peps/pep-0002/
(the PEP is a bit outdated, but it still provides a good basis for the process)
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Oct 07 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote:
Having more competition will also help, e.g. ActiveState's PyPM looks promising (provided they choose to open-source it) and then there's pip.
Note that both PyPM and pip use setuptools as an important piece of their implementation (as does buildout), so they are technically the competition of easy_install, rather than setuptools per se.
IOW, putting setuptools in the stdlib wouldn't be declaring a victor in the installation tools competition, it'd simply be providing infrastructure for (present and future) tools to build on.
P.J. Eby wrote:
At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote:
Having more competition will also help, e.g. ActiveState's PyPM looks promising (provided they choose to open-source it) and then there's pip.
Note that both PyPM and pip use setuptools as an important piece of their implementation (as does buildout), so they are technically the competition of easy_install, rather than setuptools per se.
IOW, putting setuptools in the stdlib wouldn't be declaring a victor in the installation tools competition, it'd simply be providing infrastructure for (present and future) tools to build on.
I'd like to see PEP 370 (user site-packages folders) compatibility as a pre-condition of moving Distribute (or components of it) into the standard library.
There are some issues around PEP 370 for alternative implementations that I'd like to address as a compatibility fix for Python 2.6 as well. :-)
Michael
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
On Wed, 07 Oct 2009 12:35:18 -0700, P.J. Eby pje@telecommunity.com wrote:
At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote:
Having more competition will also help, e.g. ActiveState's PyPM looks
promising (provided they choose to open-source it) and then there's
pip.
Note that both PyPM and pip use setuptools as an important piece of
their implementation (as does buildout), so they are technically the
competition of easy_install, rather than setuptools per se.
IOW, putting setuptools in the stdlib wouldn't be declaring a victor in
the installation tools competition, it'd simply be providing
infrastructure for (present and future) tools to build on.
PyPM client relies on pkg_resources only[1]. Specifically for
1) the version comparison algorithm:
$ grep pkg_resources pypm/client/version.py import pkg_resources return cmp(pkg_resources.parse_version(pkg1.version), pkg_resources.parse_version(pkg2.version))
2) parsing the "install_requires" string:
$ grep parse pypm/client/dependency.py return [pkg_resources.Requirement.parse(reqstring)
Both these features are definitely worthy of addition to stdlib but only
after standardizing them (like PEP 376 does with .egg-info structure and
files list). Now that Distribute is getting some visibility, it will be
extremely good for the community to add distribute-0.7 (which would
include the above two features apart from others) to the stdlib.
-srid
[1] The backend code (our mirroring component) also uses
setuptools.package_index
On Wed, Oct 7, 2009 at 10:43 PM, Sridhar Ratnakumar sridharr@activestate.com wrote:
PyPM client relies on pkg_resources only[1]. Specifically for
1) the version comparison algorithm: [...]
2) parsing the "install_requires" string:
[...]
Both these features are definitely worthy of addition to stdlib but only after standardizing them (like PEP 376 does with .egg-info structure and files list). Now that Distribute is getting some visibility, it will be extremely good for the community to add distribute-0.7 (which would include the above two features apart from others) to the stdlib.
Three remarks :
Distutils contains already a version comparison algorithm, and the version comparison algorithm is being reworked in PEP 386. The goal is to provide a version scheme that allows adding a field like install_requires in PEP 341, and would allow package manager to compare versions.
The roadmap of Distribute includes the splitting you are mentioning
I don't think that adding Distribute-0.7 to the stdlib it the best plan : I'd rather see bits of them included in Distutils, with Distribute being an incubator because its release cycle is shorter.
I will push on python-dev a detailed roadmap of Distutils we had in mind and what it means for Python 2.7. Give me a day or so to prepare it.
Regards Tarek
P.J. Eby wrote:
At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote:
Having more competition will also help, e.g. ActiveState's PyPM looks promising (provided they choose to open-source it) and then there's pip.
Note that both PyPM and pip use setuptools as an important piece of their implementation (as does buildout), so they are technically the competition of easy_install, rather than setuptools per se.
IOW, putting setuptools in the stdlib wouldn't be declaring a victor in the installation tools competition, it'd simply be providing infrastructure for (present and future) tools to build on.
I'm sure that some implementation of some of the concepts of setuptools will end up in the stdlib - in a well-integrated and distutils compatible form.
Perhaps we can even find a way to remove the need for .pth files and long sys.path lists :-)
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Oct 07 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
At 10:46 PM 10/7/2009 +0200, M.-A. Lemburg wrote:
P.J. Eby wrote:
At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote:
Having more competition will also help, e.g. ActiveState's PyPM looks promising (provided they choose to open-source it) and then there's pip.
Note that both PyPM and pip use setuptools as an important piece of their implementation (as does buildout), so they are technically the competition of easy_install, rather than setuptools per se.
IOW, putting setuptools in the stdlib wouldn't be declaring a victor in the installation tools competition, it'd simply be providing infrastructure for (present and future) tools to build on.
I'm sure that some implementation of some of the concepts of setuptools will end up in the stdlib - in a well-integrated and distutils compatible form.
Perhaps we can even find a way to remove the need for .pth files and long sys.path lists :-)
Setuptools doesn't require either of those now. Installing in flat, distutils-compatible format has been supported for years, and .pth files are only needed for good namespace package support. But PEP 382 makes namespace packages possible without .pth files, so even that could go away.
P.J. Eby wrote:
At 01:14 PM 10/6/2009 -0700, Guido van Rossum wrote:
suggest nobody hold their breath waiting for setuptools 0.7.
I've never suggested or implied otherwise.
But, if you like Distribute so much, why not just add it directly to the stdlib? ;-)
There are many wins to be had from such a move, not the least of which is that it allows something to go into the stdlib that isn't (branding-wise) associated with me or setuptools, and lets it become owned/supported by an even wider community.
I think the biggest problem here is that the brand ("setuptools") is so ingrained in the world that someone releasing something setuptools-but-not-setuptools ("Distribute") is at a serious disadvantage. Your insistence on retaining the name "setuptools" for yourself and your vapor-ware only harms the community at-large.
Even experienced developers are unaware of Distribute's existence.. I was entirely unaware until yourself and PJE got in a bickering exchange on Python-Dev this past month. The extremely high visibility of your stale package compared to their non-stale package is quite unfortunate. You are free to say, "that is their problem," but you are not free to say, "it is not my fault."
AFAIK, the only reason they've had multiple releases of it is to address the issues with its hijacking of setuptools; in a stdlib version all that stuff could be dropped. Otherwise, it'd already be "mature".
IOW, you acknowledge that your own position and requiring them to tolerate the parallel existence (in the world) of setuptools harms Distribute. I fail to see how this relates to being in the stdlib. As long as it is not called "setuptools" and packages in the world say "import setuptools", then there are conflicts they will be forced to managed. And moreover, as long as a stale, perhaps buggy version of setuptools is the compatibility model they must emulate, they will have a hard time coexisting.
Less political bickering, and the some of the technical results I hoped for all along are achieved. Yay, open source.
And yet, political bickering seems to be all you are good for in this case.
</flame>
-- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
I'm not really sure how to reply to your email, since it seems to be based on several major misunderstandings. So, just a few key points:
- Distribute 0.6.x is a stable maintenance branch, much like setuptools 0.6
- Distribute 0.7 is vaporware, very much like setuptools 0.7
- Packages using distribute 0.6.x still say "import setuptools"
- Suggesting that the stdlib include the other guys' code is not "political bickering" - it's a positive proposal for moving forward that eliminates both technical and political obstacles. If you thought I was being sarcastic or ironic, you are mistaken.
At 01:22 PM 10/7/2009 -0400, Scott Dial wrote:
P.J. Eby wrote:
At 01:14 PM 10/6/2009 -0700, Guido van Rossum wrote:
suggest nobody hold their breath waiting for setuptools 0.7.
I've never suggested or implied otherwise.
But, if you like Distribute so much, why not just add it directly to the stdlib? ;-)
There are many wins to be had from such a move, not the least of which is that it allows something to go into the stdlib that isn't (branding-wise) associated with me or setuptools, and lets it become owned/supported by an even wider community.
I think the biggest problem here is that the brand ("setuptools") is so ingrained in the world that someone releasing something setuptools-but-not-setuptools ("Distribute") is at a serious disadvantage. Your insistence on retaining the name "setuptools" for yourself and your vapor-ware only harms the community at-large.
Even experienced developers are unaware of Distribute's existence.. I was entirely unaware until yourself and PJE got in a bickering exchange on Python-Dev this past month. The extremely high visibility of your stale package compared to their non-stale package is quite unfortunate. You are free to say, "that is their problem," but you are not free to say, "it is not my fault."
AFAIK, the only reason they've had multiple releases of it is to address the issues with its hijacking of setuptools; in a stdlib version all that stuff could be dropped. Otherwise, it'd already be "mature".
IOW, you acknowledge that your own position and requiring them to tolerate the parallel existence (in the world) of setuptools harms Distribute. I fail to see how this relates to being in the stdlib. As long as it is not called "setuptools" and packages in the world say "import setuptools", then there are conflicts they will be forced to managed. And moreover, as long as a stale, perhaps buggy version of setuptools is the compatibility model they must emulate, they will have a hard time coexisting.
Less political bickering, and the some of the technical results I hoped for all along are achieved. Yay, open source.
And yet, political bickering seems to be all you are good for in this case.
</flame>
-- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/pje%40telecommunity.com
P.J. Eby <pje <at> telecommunity.com> writes:
- Distribute 0.6.x is a stable maintenance branch, much like setuptools 0.6
I'm new to this particular discussion so feel free to correct me if I'm wrong, but ISTM that Distribute 0.6.x differs markedly from setuptools 0.6 in that the former has an active maintainer and the latter does not, or am I wrong about that?
Regards,
Vinay Sajip
At 08:23 PM 10/7/2009 +0000, Vinay Sajip wrote:
P.J. Eby writes:
- Distribute 0.6.x is a stable maintenance branch, much like setuptools 0.6
I'm new to this particular discussion so feel free to correct me if I'm wrong, but ISTM that Distribute 0.6.x differs markedly from setuptools 0.6 in that the former has an active maintainer and the latter does not, or am I wrong about that?
That depends on how you define "active". I haven't resigned, nor do I plan to. There's simply a long mean time between releases at the moment, and some people feel that it's too long. That's certainly their prerogative, but it doesn't mean I have to agree with such characterizations.
-
Brett Cannon -
M.-A. Lemburg -
Michael Foord -
Oleg Broytman -
P.J. Eby -
Scott Dial -
Sridhar Ratnakumar -
Tarek Ziadé -
Vinay Sajip -
Zooko O'Whielacronx