M.-A. Lemburg wrote:
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tools built on top of these core APIs compete
Should this be read as:
- remove bdist_rpm from the stdlib and let it live on PyPI
?
As one of the people who proposed this, I think it means: move
bdist_rpm, bdist_msi, etc. out of distutils, but provide some of them
with the standard Python installation. I'm certain that as part of the
refactoring and simplification of distutils we'll gradually move the
existing bdist_* commands into separate, stand-alone "things" (scripts,
callable modules, or something). We'll need to do this if only for
testing, so we may as well make them work.
Instead of removing such functionality, I think we should add
more support for standard packaging formats to distutils, e.g.
bdist_deb, bdist_pkg, etc.
Agreed.
And for eggs, there should be a standard bdist_egg, written against
the core distutils APIs (*), creating archives which other Python
package managers can then use in whatever way they seem fit.
Agreed.
Just please don't tie eggs to one specific package manager,
e.g. having to install setuptools just to run eggified packages
is just plain wrong. The format itself doesn't require this and
neither should the software shipped with those eggs.
I think that whatever we produce will need to be supported by the
standalone version of the installer portion that will be backported and
separately available.
_______________________________________________
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/archive%40mail-archive.com
