feat: Parse setup.cfg or equivalent to extract options that matter to skbuild

[rdbisme]

This should provide the parsing of all config files supported by setuptools. It extracts only the ones that skbuild inspects at early stage in the setup() function.

Close #591

[rdbisme]

PS: Does this need to work with Python 2.7?

[henryiii]

Not after #688.

[henryiii]

I'm guessing this doesn't work with package = find:?

[rdbisme]

I'm guessing this doesn't work with package = find:?

I think it should. I think there's nothing specific in setuptools.setup that handles it. So I suppose it's handled by distutils?

[rdbisme]

I'm guessing this doesn't work with package = find:?

I think it should. I think there's nothing specific in setuptools.setup that handles it. So I suppose it's handled by distutils?

@henryiii you're right, this doesn't work for find:. Any idea where that is handled in the setuptools machinery such that I can give a look?

Also, can that be done in a future MR?

[henryiii]

The ideal way to do this I think is to use run_setup, https://github.com/python/cpython/blob/2efe18bf277dd0f38a1d248ae6bdd30947c26880/Lib/distutils/core.py#L170 for example, which would leave the parsing to setuptools and then we could query the options from there. The method in this PR also won't support pyproject.toml configuration, which I'd like to support as well if possible. @abravalheri might have some comment on the best way to pull configuration before running the build?

[abravalheri]

@henryiii is right, using something like:

from setuptools.dist import Distribution  # <-- setuptools needs to be imported first
from distutils.core import run_setup

if os.path.exists(setup_script):
   dist = run_setup(setup_script, stop_after="init")
else:
   dist = Distribution({"script_name": "%notset%", "script_args": []})

dist.parse_config_files()
# dist attributes have now be filled in by config files.

Should do the trick... However note that people using SETUPTOOLS_USE_DISTUTILS=stdlib can experience some issue depending on how they write setup.py scripts, because the original version of distutils has worse encoding handling.

(It may also not work 100% if people are trying hard to hack setuptools in their setup.py files)

[abravalheri]

I would be very interested in following what you guys have in mind and see how it plays out. I have proposed a very similar change in the past for setuptools.build_meta, but I decided to leave it out for the time being.

I previously mentioned "hacking" in setup.py. What I have seen so far is people trying to run ad-hoc build steps via setup.py without using a setuptools command. For example, some people would try to use the setup.py script to create files in build/... directory and hope that it ends up in the wheel...

[rdbisme]

What I'd like to achieve is the same behaviour as a pep517 compliant frontend. I.e. running something like a resolve_config() that automatically understands which config file to check based on pyproject.toml, doing the necessary runtime tasks to populate the Distribution object with the metadata we need to inspect.

The solution @abravalheri you suggest requires coding the logic to identify the setup_script, doesn't it?

Maybe I'll check again how build package works and see if I came up with a good idea.

[abravalheri]

Maybe I'll check again how build package works and see if I came up with a good idea.

You are probably looking for pep517.meta.load (I don't know how public this function is considered to be).

The caveat is that this function does run part of the build process, specifically prepare_metadata_for_build_wheel. It is very heavy weight also...

The solution @abravalheri you suggest requires coding the logic to identify the setup_script, doesn't it?

Just assume setup.py... The important part is to check if a setup.py script actually exists at the root of the project or not.