Add support for ext_modules in static setup.cfg

In the process of porting an old project from the now defunct d2to1 I noticed a feature of d2to1 that is still missing from setuptools is support for configuring extension modules in setup.cfg.

At least, that’s what my reading of the source suggests, especially ConfigOptionsHandler

In d2to1 this looks something like:

[extension=<module_name>]
sources = <file1> <file2> ...
language = c
<keyword> = <value>

where each key/value pair correspond to setuptools.Extension arguments.

For setuptools it might look something more like:

[options.ext_modules.<module_name>]
<key>=<value>

Though I’m open to other suggestions for the format, and would be happy to provide a PR once we agree on and nail down a format.

[samvv]

Does there happen to be a roadmap for this? I’d be very interested to see this happen.

[embray]

I agree with your point about using a different delimiter to separate the config namespace from the module name. I’m fine with :, I think it’s a good choice.

One problem with all this I realized, is that while it would work fine for simple cases, I noticed that it’s still fairly common in several of my packages to involve a little bit of code in configuring extension modules. Most commonly was using numpy.get_include() to get the path to the Numpy headers. Another is using cythonize to build Cython modules. In d2to1 I believe I included special cases for both of these, but hard-coding special cases doesn’t scale well.

Of course, this could get arbitrarily complex to the point where not every case can be supported in a static config. I think there could be a way for code to provide extensions to the syntax while still allowing most of the configuration to be static. But maybe as a first pass it would be best to just implement the “obvious” static configuration and then figure out more complex cases later.