Pluggable hooks for parse_configuration

[KOLANICH]

Look at
https://github.com/pypa/setuptools/blob/master/setuptools/config.py#L104L110

It's hardcode. It prevents from extending configuration parser with custom specs for setup.cfg. For example setuptools_scm cannot be set up via setup.cfg. Or my new extension.

I propose to plug endpoints here.

[jaraco]

@KOLANICH Can you elaborate? What interface do you propose to be extensible? How would setuptools advertise/solicit these extensions? I'm skeptical that such a pluggable interface will be viable or desirable, so anything you can do to persuade this project that it's a good idea will help move this issue forward.

[KOLANICH]

What interface do you propose to be extensible?
I guess it is obvious: I propose replacing the hardcode with entry_points.

So
1 create an array
2 retrieve entry_points (can entry poins be classes?)
3 popupate the array with constructors of types derived from ConfigHandler with the signature (self, target_obj, options, ignore_option_errors=False)
4 in parse_configuration iterate over array, construct them and call parse

It's a naive way. It slows down with the count of extensions registered. There is a better way, provide metadata binding section names to the extensions and build a dict and lookup it on unknown section occurence. So they should only be called if the section has actually occured.

[RonnyPfannschmidt]

actually we could just register config keys the same way we register distribution obptions, or even reuse that

[abravalheri]

If I understood correctly this feature could be useful for implementing things like:

...
ext_modules = cytonize: file.pyx
...

or

[options.ext_modules.cytonize]
primes = 
    sources = primes.pyx
    include_dirs = [...]
    libraries = [...]
    library_dirs = [...]

right?

If that is the case, I think the feature would be very desirable... Even though it is very straightforward doing extensions directly in setup.py, information about the package cannot be easily extracted from it without executing the script. Since setup.cfg is just a plain serialized data structure, it is much easier to parse, and therefore can be used by external tools for several purposes...

Additionally, it allows offloading some responsibilities from the setuptools core. In the aforementioned example, implementing the (de)serialization of the extension descriptor objects to be stored in setup.cfg could be the responsibility of a third-party package, or even Cython itself.

Another example I could think of is:

long_description = orgmode: README.org

I hope this helps to clarify the scenario where this kind of pluggable hook could be used.

[wookayin]

@KOLANICH Has this been completed? If so, how can we make it?