[Distutils] Alternate static metadata PEP submission...

[David Cournapeau]

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