David Lyon wrote: > On Tue, 27 Oct 2009 16:52:36 +0000, Chris Withers <[email protected]> > 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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
