[Distutils] Alternate static metadata PEP submission...

David Cournapeau david at ar.media.kyoto-u.ac.jp
Wed Oct 28 04:26:19 CET 2009


David Lyon wrote:
> On Tue, 27 Oct 2009 16:52:36 +0000, Chris Withers <chris at simplistix.co.uk>
> wrote:
>   
>> from distutils.core import setup,parse_static
>> setup(**parse_static('setup.cfg').to_dict())
>>
>> ...and of course, because setup.cfg is the default name, we just end up 
>> with:
>>
>> from distutils.core import setup
>> setup()
>>     
>
> Nice..
>
> But one still ends up with a user based setup.py
>
> After OPs comments about security I'm totally convinced that we need
> to ban setup.py

You can't ban setup.py: although a lot of packages can rely on a purely
declarative package description, some package won't be able to do so
(unless your declarative thing ends up being a full language).

We should certainly encourage people to use declarative description, as
this works for most packages out there, but it should be more flexible
if desired.

>  or at a very minimum move a standard setup.py into 
> distutils itself.

With toydist, there would be a new build system not based on distutils,
and which would indeed works like this. Assuming you have a static file
toydist.info, I would have something like:

toydist configure --prefix=/home/david/local
toydist build
toydist install

Or even, for a default build:

toydist install (which would do configure and build automatically).

But more importantly, note how people who want to use setup.py still
can, how people who want to use another system can (through the python
API around the static description). This gives a way forward to a system
not tied to distutils legacy: this is very flexible, would keep all the
feature given by setuptools/distribute, and would enable people like me
who are convinced that distutils design is fundamentally flawed for
heavy-weight build needs.

David


More information about the Distutils-SIG mailing list