[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.
>>
>> http://wiki.python.org/moin/DistutilsVersionFight
>> http://wiki.python.org/moin/Distutils/ManifestPluginSystem
>> http://wiki.python.org/moin/Distutils/Metadata
>> http://wiki.python.org/moin/Distutils/StaticMetadata
>> http://wiki.python.org/moin/Distutils/StandardizeEggInfo
>>

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.

For users:

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
bill here.

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
Wiki.

Thanks

--erik


More information about the Distutils-SIG mailing list