Tarek, On Sat, Apr 18, 2009 at 2:23 AM, Tarek Ziadé <ziade.ta...@gmail.com> wrote: > On Sat, Apr 18, 2009 at 11:09 AM, Lennart Regebro <rege...@gmail.com> wrote: >> Setuptools non-support for Python 3 is currently a serious hindrance >> towards Python 3 aceptance. I'm trying to figure out what to do as a >> next step in the Python 3 support for setuptools. And I have >> encountered some obstacles. The first one is that setuptools requires >> itself for installing and running tests. That makes it hard to install >> it under Python 3. There are various solutions to this, but the next >> obstacle I encounter in choosing the right solution is that the code >> is hard to understand, and it makes me want to just rip it out and >> start over, or in even more frustrated moments, avoid the problems by >> not using setuptools at all. But the third obstacle for that is that I >> don't actually know what features of setuptools people use. >> >> I personally use setuptools for these reasons: >> >> 1. When I create projects with paster, it uses setuptools. >> 2. Setuptools makes it possible to specify requirements, which is then >> used by buildout. >> 3. Namespace packages require pkg_resources? >> 4. The test command. >> >> What are the other major reasons people use setuptools?
I ideally would like to use setuptools like pkg_resources for establishing the requires functionality to ensure that the versions of the packages I'm dealing with are legitimate and tested. Having a uniform versioning mechanism would greatly simplify bug reporting and triage, not just within the python community, but also in any communities outside of python that use / distribute python utilities / modules. > entry points (in the "how to extend commands" topic I might propose to > include it/use it but it would need to be separated > from pkg_resources) > >> Is there any good reason to not extract the namespace package support >> into a separate package? > > It's on its way http://svn.python.org/projects/peps/trunk/pep-0382.txt > > and PEP 345 is being reworked to include requires > http://svn.python.org/projects/peps/branches/jim-update-345/pep-0345.txt I realize that PEP 345 isn't your PEP, but if you could relay this to the authors, it would be much appreciated: The section... Supported-Platform (multiple use) Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary package was compiled. The semantics of the Supported-Platform field are not specified in this PEP. Example: Supported-Platform: RedHat 7.2 Supported-Platform: i386-win32-2791 ... isn't 100% complete in my mind. Will version checking of the OS be properly supported so I can say: Supported-Platform: RedHat (>7.2) ... to say that Redhat 7.2+ is supported? I say this because certain versions of FreeBSD have certain featuresets that were introduced in later versions (most notably the ones that are basically fixing pthread and rt support with multiprocessing), and specifying a version range would be helpful. If it's not within the scope of the PEP at all to address this point, this point should be referenced wherever it exists in other documentation. > Anyways, you can probably help if you worked on pkg_resources, by > splitting all its components in pep-8-ied, readable elements > in your branch Thanks, -Garrett _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
