[Distutils] Distutils changes - end user requirements (Was: Deprecate MANIFEST.in)
Erik S. LaBianca
erik.labianca at gmail.com
Wed Apr 8 17:07:04 CEST 2009
On 4/8/09 6:27 AM, Paul Moore wrote:
> 2009/4/8 Tarek Ziadé <ziade.tarek at gmail.com>:
>>> Nobody seems to be attempting to collect requirements here.
>> I do, in the wiki. I am trying to synchronize the work done at Pycon, and
>> in the future. I am trying to synthethize the needs there.
Perhaps it would be a worthwhile effort to create a
DistUtilsRequirements page on the Wiki? I think we all agree that the
current situation needs help, but what is in scope for distutils and
what needs to be supplied via plugins and third-party tools? I'm sure
for many of you this seems obvious, but I think the flame wars are in
part due to differing understandings of the goal.
Off hand, here are some of the requirements I perceive for the packaging
ecosystem on the whole. I do not think all of them should be met by
distutils proper, but the overall ecosystem of python packaging tools
needs to provide solutions for all of them.
1. Simple package installation following the conventions of their
platform. IE apt-get, aptitude, yum, synaptic, ports, msi.
2. Simple package installation following python conventions. IE
easy_install, pip or whatever activestates thingy was called.
3. Simple installation including necessary dependencies. IE easy_install
or apt-get. Raw rpm, deb, or msi installs don't follow this.
4. Simple application installation or deployment following both the
"system managed" and "application managed" models Tarek alluded to.
For distribution packagers:
1. Dependency meta-data. I can't make packages for appA that work
correctly without knowing that it depends on libB version 1.0 or greater.
2. Declarative meta-data in the sdist. I need to be able to unpack an
sdist file and pull out all the information i need to build packages
without connecting to your dvcs or installing a bunch of third party stuff.
3. Rational versioning. I need to know how to express python package
versions in a way I can map it's version number to the versioning scheme
I use. IE RPM, Deb, PyPi.
4. Build tools. I don't want to become an expert on cython, swig,
setuptools, or anything else. I want a standard mechanism to build
packages regardless of their complexity. Distutils bdist sorta fits the
5. Reproducible sdists. I want to be able to take your package, make a
small change, and rebuild the package without having to connect up to
your vcs to do it.
For package authors:
1. Easy builds for my own use and distribution. IE create setup.py,
./setup.py bdist_rpm, use the package! I get the impression setuptools
is the more modern way to do this, but I must claim ignorance, personally.
2. Easy integration with VCS so I don't forget to include newly added
files etc. Nobody wants to manually update MANIFEST, or MANIFEST.in, if
the information needed is already in VCS.
3. Support for building C extensions and the like. Distutils covers this
pretty well now, I think.
4. Support for including "run scripts", hacking documentation, user
documentation, support data files, etc. These need to be flagged in the
metadata so distribution packages know what's what.
I'm sure there's a lot more. If there's interest, I'll be happy to try
to consolidate others contributions and clarifications and put it on the
More information about the Distutils-SIG