i can shed some light on the context here
pbr is the build system we use for openstack.
pbr wraps setuptools and delegates most of the heavy lifting to setup tools.
setuptools wraps distutiles and both setuptools and distutils supprot extendtions.
pbr uses the extendtion functionatlity to defien a new entrypoint wsgi_scripts which uses a factory function to generate a standardised wsgi script for all openstack rest api.
each openstack project that has a reset api uses the wsgi_script entrypoint
here is an example of how that is used in the nova project
nova-api = nova.cmd.api:main
nova-api-metadata = nova.cmd.api_metadata:main
nova-api-os-compute = nova.cmd.api_os_compute:main
nova-compute = nova.cmd.compute:main
nova-conductor = nova.cmd.conductor:main
nova-manage = nova.cmd.manage:main
nova-novncproxy = nova.cmd.novncproxy:main
nova-policy = nova.cmd.policy:main
nova-rootwrap = oslo_rootwrap.cmd:main
nova-rootwrap-daemon = oslo_rootwrap.cmd:daemon
nova-scheduler = nova.cmd.scheduler:main
nova-serialproxy = nova.cmd.serialproxy:main
nova-spicehtml5proxy = nova.cmd.spicehtml5proxy:main
nova-status = nova.cmd.status:main
nova-api-wsgi = nova.api.openstack.compute.wsgi:init_application
nova-metadata-wsgi = nova.api.metadata.wsgi:init_application
as you can see the syntax is identical to console scripts and the behavior is also the same
the only thing that differs is the waht the script is generated in pbr
pbr uses a diffent template for the content of the generated script but its installed in exactly the same way and in the same location as the generated console scripts.
this has not been a problem until rechent version fo pip which started moving to pep 517/660 support
recently we moved our ci system to install openstack in a singel global virtual env instead of
doing “sudo pip install -e ” that is to prepare for the upcoming changes
to debian/ubuntu where that will be blocked
in doning that we discuoved it did not work on centos 9 stream
so for centos we left it install globally instead of in a vnev.
i started looking into why that was failing 2 weeks ago and discover that it was related to teh recent release fo pip which removed calling setup.py as a fallback if pyproject.toml nont found.
instead new version of pip invent calls to setuptools internally when a setup.py is present and that does not use pbr. as a result our wsgi_scripts entry point is not processsd and the rest apis cannnot start as the wsgi script are not found.
the obvious soltion seamed to just be add pyporject.toml to all the openstack repos
which i started here.
pbr already support building with pep-517 after all so that shold be a small change.
that where teh prblems begin becasue that almsot worked perfectly exception for one edge case.
pbr did not supprot pep 660 editabel wheels that was fine excpte for the fact
we use tox for unit/functional test. for reasons we run your py39 tests on ubuntu 20.04 which has py38 as its default interperter. thats fine ubunut hase py39 avaiable as a package so we just insall it.
adding a pyproject.toml file is enough to enable isoloaded build
with tox that means that the wheel is build in a seperate tox venv “.pkg” and that venv uses you systems base python in the case py38
we are building universal wheels so that should not be a probelm excpet when that wheel is installed into the py39 venv pip hard fails saying that the backend (pbr) does not supprot editable mode.
this only happens when using a different .pgk python veriosn for the test venv.
so again the fix seams simple lets just add support to pbr for pep 660 so that it can supprot editabel_wheels
so we did that and we did a 6.0.0 release which fixed our unit tests.
the change in pbr just delegates to setuptools to do the heavy lifting
this si where the problems start.
neither setup tools or pip know about wsgi_scripts
setup.py develop is not being called anymore so pbr cannot hook that to install the wsgi scripts ourslevs
and the console_script setup.py install_scripts command is not being used either.
the problem stems form teh fact that pep-660 did not standardise supprot for script or datafiles
it gave special status to console_scripts and gui_scripts and did notn provide a way to execute other script handelers.
so for openstack to supprot pyproject.toml we need a way to adress this gap as this si a blocker for use to consinute adding supprot for this going forward.
im not sure thtat adding wsgi_script is the best way to do that and i woudl prefer a more generic way to refernce a handler function that will be used to render the templsate with a standard set of args.
if anyone has adviace as to which of the three standardised function in pep660 could be abused in the interim to generate the wsgi scripts
build-editable, get-requires-for-build-editabl, or prepare-metadata-for-build-editable
i could try and make pbr do somethign fomr there but the issue is not really with the wheel building but the installation.
building a non editable wheel with pbr does include the scripts in teh wheel
the problem is we now have no generic way to install them.
in the ediable case they are not generated at all because the hooks we were using are nolonger used.