[Distutils] Questionnaire: Why do you use setuptools?

[Garrett Cooper]

Tarek,

On Sat, Apr 18, 2009 at 2:23 AM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
> On Sat, Apr 18, 2009 at 11:09 AM, Lennart Regebro <regebro at 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