On 4/8/09 6:27 AM, Paul Moore wrote: > 2009/4/8 Tarek Ziadé <ziade.ta...@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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig