On Sat, May 4, 2024, at 9:08 AM, Dmitriy Rabotyagov wrote:
Oh, well, totally, we do install wheels.
But then... In suggested series of patches "wheels" is defined in pyproject.toml, ie patch for the keystone [1]
Which means that it will get installed as well. Like I kinda get that we wanna pyproject.toml to exist to support PEP 517, but then I'm not sure I understand how removal of wsgi scripts [2] is really required? Or we add wheels there just for transition to remove it later? As like in nova patch [3] I already don't see wheels.
Sorry for these stupid and obvious questions, but I am apparently severely lagging behind this topic. As I persuaded is - there's no way to build/install services with wsgi-scripts starting from pip 23.1 and that appeared to be only partially like that.
The problem is only present when making editable installations aiui because the hooks to generate and install the wsgi script don't run when doing an editable install.
As like reading to the PR introducing removal of behaviour [4], it kinda feels that installing `wheel` is pretty much an "assumed" way of package installation? Which lead me to a faulty impression, that what we're fighting with right now might be just a specific way how devstack performs installation and might be that is what might be adjusted instead of removing wsgi-script?
I think the concern is that the changes that break editable installs are just the tip of an iceberg sized set of changes that will impact these sorts of PBR special behaviors. By addressing this early, we ideally avoid needing to scramble when you can't install wsgi scripts at all. Additionally, the proposed path forward is that we rely on more standard packaging tool options rather than continue to invest in trying to keep all of these PBR specific functions working as upstream makes major changes to how packaging works. This means we've got an upfront transition cost but once that is done we should be good for a while rather than needing semi regular PBR maintenance to adjust to changing APIs.
I totally get that my assumption is totally wrong in many places, but as I said - I'm lagging behind on this topic, unfortunately, and trying to catch up.
[1] https://review.opendev.org/c/openstack/keystone/+/899519/4/pyproject.toml [2] https://governance.openstack.org/tc/goals/proposed/migrate-from-wsgi-scripts... [3] https://review.opendev.org/c/openstack/nova/+/899753/11/pyproject.toml [4] https://github.com/pypa/pip/issues/8559
On Sat, May 4, 2024, 16:03 Mohammed Naser mnaser@vexxhost.com wrote:
Could it be that you have wheel installed?
https://github.com/pypa/pip/issues/8559
Get Outlook for iOS ________________________________ From: noonedeadpunk@gmail.com noonedeadpunk@gmail.com Sent: Saturday, May 4, 2024 4:35:21 AM To: openstack-discuss@lists.openstack.org openstack-discuss@lists.openstack.org Subject: Re: [all][packaging][release][qa][tc] pep-517 and pip 23
Hey,
Sorry, I'm getting slightly confused about this topic right now as I don't understand how we made our process work with PIP 23.3.2 on Caracal while still using WSGI path...
So I've pinned PIP to 23.3.2 for OpenStack-Ansible out of interest basically, but realized everything works with zero changes to anywhere.
Firstly, I thought that it's because we do build wheels in our own, which potentially can workaround temp wheel build by pip. But then I've realized that we have bunch of jobs that explicitly skip wheel build, and they're passing as well.
Example: That new pip is used: https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fzuul.opend...
And uWSGI is configured to use file path: https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fzuul.opend...
So question is - what I'm really missing? Or well, why I have impression that it works?:) As it seems that pyproject.toml implementation is not merged yet according to [1].
[1] https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.ope...