[Python] passing options to back-end setuptools when invoking python -m build

I've just started converting my direct invocation of setup.py to using the build module, pyproject.toml to provide the recommended separation of front-end invoking the back-end build mechanism (setuptools in my case). I'm running into an issue when trying to convey the --tag-build option for setuptools to utilize (our CI/CD builds need finer granularity with regard to the default timestamp provided by the --tag-date option, because of how pip caching works, needs to include HHMMSS value in the timestamp). I've been the following sample command line (using Python 3.10.8) python3 -m build --wheel '--config-setting=--build-option=-v' '--config-setting=--build-option=egg_info' '--config-setting=--build-option=-bpost20240119000000' Stepping though the build/__main__.py's main function, the above command line appears to be properly parsed, the config_settings list has the various arguments for the back end: config_settings == { '--build-option': [ '-v', 'egg_info', '-bpost20240119000000']}. My understanding is that this list is then conveyed to the backend. Unfortunately, I've yet to figure out why the Pycharm debugging is failing in the _build_in_isolated_env().

I'm hoping others can share how they got these egg_info options utilized by the build module to achieve the intended effect. Or perhaps, additional steps I can take to track down the root cause.

I appreciate any feedback, suggestions. MTIA.

output of the build invocation:

$python3 -m build --wheel '--config-setting=--build-option=-v' '--config-setting=--build-option=egg_info' '--config-setting=--build-option=-bpost20240119000000' |& tee build-failure.log
* Creating venv isolated environment...
* Installing packages in isolated environment... (setuptools>=42, wheel)
* Getting build dependencies for wheel...
* Installing packages in isolated environment... (setuptools>=50.3.2, wheel, wheel>=0.35.1)
* Building wheel...
/tmp/build-env-9qdhq0jy/lib/python3.10/site-packages/setuptools/config/_apply_pyprojecttoml.py:82: SetuptoolsWarning: `install_requires` overwritten in `pyproject.toml` (dependencies)
corresp(dist, value, root_dir)
/tmp/build-env-9qdhq0jy/lib/python3.10/site-packages/setuptools/sandbox.py:13: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
import pkg_resources
usage: _in_process.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: _in_process.py --help [cmd1 cmd2 ...]
or: _in_process.py --help-commands
or: _in_process.py cmd --help

error: option --dist-dir not recognized

ERROR Backend subprocess exited when trying to invoke build_wheel



pkg_resources is not present in setup.py, setup.cfg, pyproject.toml nor is --dist-dir.

The python3 ./setup.py egg_info -bpost20240119000000 bdist_wheel invocation has no issues, the expected dist/ioif_core-0.8.4.post20240119000000-py3-none-any.whl is created.

---- 1st update ----

adding --no-isolation to the build options -> the wheel is generated, placed in dist/ but the -b option is not utilized (wheel file: dist/ioif_core-0.8.4-py3-none-any.whl). So, new questions I need to dig into: what's wrong with using an isolated virtualenv vs none; what's happening with egg_info -b

---- 2nd update ----

This is using setuptools 60.2.0. Is the philosophy of the PEP517 packaging now that metadata should be set accordingly rather than depend on legacy commands such as egg_info -b ? So a backend should expect project metadata to drive aspects such as versioning? So, while setuptools still documents using the egg_info -b to tag daily builds, etc, without the build front-end conveying these options (I'm seeing that _buid_with_temp_data() in build_meta.py is not conveying the non-global-option options to the build process), only updating the metadata seems viable.

In that spirit, I modified (so far) a setup.py to extract (prior to invoking setup) the version value from either pyproject.toml or setup.cfg & if set, with an env variable defining a format string, generate the resulting version value, conveying as named argument to setup). That works great but only if --no-isolation is used when invoking python3 -m build. I have a print statement showing the correct version value in both scenarios but it's not being used unless I use --no-isolation. I like the isolation env concept in PEP517, would prefer to use it but in a CI/CD job, not much added value so -n is looking like a time saver. Is there even an build option to not rm the temporary build env so post-build analysis of what is there can be done?

Continue reading...