| I've had a similarly frustrating time trying to understand and wrangle the pyproject.toml builder system, (egg-layer? wheel-roller? cheese-monger?) One thing the author might want to try is writing their own "build-backend". You can specify your own script (even use setup.py) and that will be the target of python -m build or pip wheel or presumably whatever build-frontend you use. # pyproject.toml
[build-system]
requires = ["setuptools"]
build-backend = "setup" # import setup.py as the build-module
backend-path = ["."]
Then in setup.py you should write two functions: def build_sdist(sdist_directory, config_settings):
...
def build_wheel(wheel_directory, config_settings, metadata_directory):
...
Where config_settings is a dictionary of the command line "--config-settings" options passed to the builder. (sys.argv does not have access to the actual invocation, I suppose to ensure frontend standardization)example: $ python -m build --config-setting=foo=bar --config-setting=can-spam
# will call
>>> build_sdist("the/dist/dir", {"foo": "bar", "can": "spam"})
Of course, you can extend the default setuptools build meta so you only have to
do the pre-compilation or whatever your custom build step requires: from setuptools.build_meta import build_sdist as setuptools_build_sdist
def build_sdist(sdist_directory, config_settings):
# ... code-gen and copy files to source ...
# this will call setup.py::setup, to make things extra confusing
return setuptools_build_sdist(sdist_directory, config_settings)
I had to create a temporary MANIFEST.in file to make sure that the setuptools
build_sdist saw the generated files. Maybe there's a better way?
I think the wheel "just" packages whatever the sdist produces, though that might be more difficult if you're compiling .so files or whatnot.Still overall pretty fiddly/under-documented and a shame there seems to be a push for more dependencies rather than encouraging users to build their own solutions. More info in PEP 517: https://peps.python.org/pep-0517/ |