no way to support setuptools plugin option in setup.cfg metadata

[RonnyPfannschmidt]

while experimenting with setuptools_scm metadata i discovered that there doesn't seem to be a way to add setup.cfg metadata support to setuptools plugins

[pganssle]

I think I generally get what you mean, but @RonnyPfannschmidt can you provide a minimal example of what you have in mind?

[RonnyPfannschmidt]

@pganssle setuptools_scm has a mode of operation where a mapping with different keys and types is passed as a argument to the setup call, currently its impossible to transfer that

see https://github.com/pypa/setuptools_scm for examples of invocations

i haven't yet made up a minimal example, but something similar to find: might help

[pganssle]

Hm.. Would it make sense to put it under a tool heading, like so?

[tool:setuptools_scm]
use_scm_version=True

I'm not clear on whether it's possible to achieve your aims already by just having setuptools_scm parse the config file and extract its sub-heading (pytest already does this, for example, though it's mostly unrelated to setuptools).

[RonnyPfannschmidt]

@pganssle that would be a failure - setuptools provides a extension mechanism for setup calls, but denies it for setup.cfg

also if a custom config parser was needed, then the only sane option those days would be pyproject.toml

but even then setuptools should provide the config content in a parsed form

[pganssle]

@RonnyPfannschmidt Well, plugins can put their configuration wherever they want, but there's standard library support for setup.cfg, but not for pyproject.toml, and you're asking for more stuff to go into setup.cfg in the first place...

In any case, I'm just saying there's already a well-established place for tools to put their configuration in setup.cfg, and usually when options are added to setup.cfg, they go under a heading not present in setup.py - note that setup() doesn't look like this:

setup(metadata=dict(
    name='mypkg'
    version='0.0.1'))

The fact that setup() takes a bunch of loose keys for the configuration doesn't mean that setup.cfg can't expect those keys to be namespaced or categorized. To me the natural place to namespace such keys would be under tool-specific configuration headers.

Now, I don't know how pytest implements this [tool:pytest] parser. If it's super inconvenient it makes sense for setuptools to provide some hooks for it, but I think that that's the rough shape that the solution should take, and it's already available today.

[jaraco]

setuptools provides a extension mechanism for setup calls

Right - that's the distutils.setup_keywords entry point, that allows arbitrary third-party packages to solicit parameters when setup() is called and invoke hooks in those packages to supply behavior for those keywords. setuptools_scm defines use_scm_version as a distutils setup_keyword.

[jaraco]

What setuptools_scm needs is not a place to define configuration, but a way for declarative config to trigger the hook that would import setuptools_scm and allow it to customize the Distribution.