David Lyon wrote:
You need to detect cython (configuration stage)
cython is a type of python interpretor? like jython or ironpython
Cython is a language which is more or less a subset of python, with optional typing, and cython is the name of the Cython -> C compiler. It is one of the tool of choice to speed up python code in the python scientific community.
[Application] scripts = artisticflairgui.py
[Application cython] scripts = artisticflairguicython.py
That's a different file being installed if we detect we are using cython and not python.
The usual pattern is: code = ['artisticflairgui.py'] if has_cython: code.append(Extension('_foo', sources=['artisticflairgui.pyx'])) You need commonalities between 'subsections' (which one another problem of the current usage of .ini-like format).
This is similar to my main complain about distutils: you can't easily share data between commands. AFAIK, the only way to do it is to use the Distribute class instance, which is problematic as that's what most tools on top of distutils need to monkey-patch.
It seems to be a really unusual (for me) problem.
It is a unusual problem if you are a user of distutils - it is a major problem if you want to extend distutils. Most if not all implementation problems of setuptools/paver and the like are rooted to this. For example, to build eggs, setuptools needs some info between its different egg commands, and the way to do it is to create its own Distribution subclass. Now, when we in numpy extends the Distribution class by ourselves, we have to take into account whether setuptools is used or not, and track the changes. Distribute fork only makes matter worse. That's why when people complain about setuptools hacks, they should give its authors some slack: the problem is rooted in distutils, and there is simply no way to fix this, short of rewriting distutils from scratch or breaking it so badly that there is no point reusing most of its current code. I see the use of metadata files as we are discussing here as the way forward for backward compatibility: a distutils command would convert a setup.py-based to the metadata, and the new tool would takes this. The metadata are the compat layer, not the distutils implementation anymore. In that perspective, the current .ini-based proposal (PEP 390 and yours) seems too weak to support a significant subset of existing code. David