[all][packaging][release][qa] pep-517 and pip 23
hi folks,
TL;DR ----- this is a long email so the tl;dr is we should add pyproject.toml ``` [build-system] requires = ["pbr>=5.7.0", "setuptools>=36.6.0", "wheel"] build-backend = "pbr.build" ``` to all openstack projects to supprot pip 23.1+
Long version ------------ As some of you may know the ptg happend last week an done of hte topic raised there was a know limitation in devstack where GLOBAL_VENV=True does not work on centos/fedora derived distros.
while i generally dont use centos/fedora derived distros for my daily work i have been using devstack for over 10 years at this point so when im told it broken i ocationlly will go fix it. In this case the issue is not with devstack (it often isnt) and is actully in our collective reliance on a deprecated functionality and how we package openstack today.
Back story, for better or worse when openstack was created the landscape of python packaging was significantly different then it is today. To help corodinate our dependcies the openstack comunity went all in on requirements.txt and developed upper-constraits to manage our requirements and developed PBR (python build Reasonableness). both of those approches have served us well and likely will continue to do so for some time. Since then pyproject.toml has started to gain popularity and pep-517 (A build-system independent format for source trees) has been adotpted but so far openstack as a comunity has not embraced those changes. (although pbr already supprot pep-517 :) ). Until now this has not been a problem however with recent release of pip things are now breaking.
Problem Context: - openstack does not provide pyporject.toml files - openstack project configure setuptools to use pbr via setup.py - setuptools support generating scripts form entry points(console_scripts) which we use for project binaries( nova- compute, neutron-server, ...) - openstack api services use a pbr extension know as wsgi_scripts which adds a similar functionality for generating wsgi application mains file - devstack due to coming changes in distro to block "sudo pip install" now installs openstack in a single by default on debian distros. on centos/fedora distros it currently almost functional (but not). - devstack installs in editable mode because that is how most developers use devstack for developemnt
What changed: - pip 20.2 deprecated support for falling back to calling setup.py when pyproject.toml is not present - https://pip.pypa.io/en/stable/news/#v20-2 - https://github.com/pypa/pip/issues/8368 - at this point when pyproject.yaml is not called pip calls setup.py install [-e] <path to repo or package name> - setup.py invokes pbr to generate wsgi_scripts and other files - in pip 23.1 the fallback was removed https://pip.pypa.io/en/stable/news/#v23-1 - pip now builds a temp local wheel instead of calling setup.py install when pyproject.toml is not found - in editable mode (-e) the default way the wheel is built does not invoke pbr properly to generate the wsgi files - as a result the wsgi files are not installed to the venv bin dir and this causes devstack to fail to start keystone (or any other wsgi api)
The fix, there are a few ways to approch this: - clamp pip (https://review.opendev.org/c/openstack/devstack/+/898845) this is a terible idea and it breaks debian - clamping pip below 23.1 works on centos for now however OVS on debian already requires pep 517 for installing - as such when that version of ovs (or other projects start enforcing that) hits centos it will break - add a minimal pyproject.toml to all openstack project - example for keystone https://review.opendev.org/c/openstack/keystone/+/899519 - this example jsut adds the minium pyproject.toml to enable pbr to be used as the build system - it does not remove supprot for setup.py but it will not be used by default going forward whit new version of pip - all config is still in setup.cfg - add pyproject.toml support but remove setup.py support https://review.opendev.org/c/opendev/bindep/+/816741 - this goes one step futrue and actuly nulls out setup.py - we could take this approach if we want to but its not required.
The reason for this email is to get agreement on how to support pip 23.1+ My proposal would be to add pyproject.toml with the minimal config required to enable pip 23.2 but not drop the setup.py support in this cycle. i would suggest that we can deprecate installing via setup.py in caracal if that is desirable but not make that change until the next slurp to give time to projects and packages to catch up.
if there are no objections to that i would like to ask what is the preferd way to create and submit the patches for the minimal pyproject.toml
``` [build-system] requires = ["pbr>=5.7.0", "setuptools>=36.6.0", "wheel"] build-backend = "pbr.build" ```
i can propose patches to the main project deployed by devstack by default. i.e. nova/neutron ectra but it might be better if someone form the core teams of each project could take on that task and chasing the reviews. if someone has a script to generate a patch for a set of repos that just add the above pyporject.toml then we can use that to keep a consistent topic/commit message across all patches.
my proposal for testing this is two fold. in ci we can test the patches are functional by using a DNM patch to devstack to force enable the gloal venv on centos and depend on the set of patches, i will modify https://review.opendev.org/c/openstack/devstack/+/898845 to do that
locally we can test that the patch is functional by doing the following substituting keystone for the relevant project. ``` git clone https://opendev.org/openstack/keystone cd keystone python3 -m venv .venv . .venv/bin/activate python3 -m pip install -U pip python3 -m pip install -e . ls .venv/bin/keystone* ```
the ls will not contain the wsgi script with the addition of the pyproject.toml it should.
on debian sid i can reproduce the same issue the problem we are seeing on centos 9 now will start impacting other distos eventually so its good to fix this now.
if i start proposing this to glance/nova/neutron/cinder/swift/horizon/placement (to get a default devstack working) can i get cores to review? can cores form each project nominate peopel to review or volenteer to do this work. i have created https://etherpad.opendev.org/p/pep-517-and-pip-23 to track this work
i have some other work that i think we can do in parallel like addign pyporject.toml support to the pti requirements if we go this way but that i think we can discuss on a governacne patch to updated it.
anyway this is a lot to digest so feedback is welcome. if someone else would like to drive this that is also welcome (i.e. tc/release team)
regards sean.
On Tue, 2023-10-31 at 14:46 +0000, smooney@redhat.com wrote:
hi folks,
TL;DR
this is a long email so the tl;dr is we should add pyproject.toml
[build-system] requires = ["pbr>=5.7.0", "setuptools>=36.6.0", "wheel"] build-backend = "pbr.build"to all openstack projects to supprot pip 23.1+
This sounds like a reasonable and likely overdue thing to do. I'm sure fungi and clarkb in particular will have more comments but my only concern of note is that adding a 'pyproject.toml' file is enough to trigger isolated builds by default. How does this affect things like Nova where not all dependencies can be specified in our requirements.txt files (e.g. libvirt)? Is there a PoC for e.g. Nova available to test this?
Cheers, Stephen
Long version
As some of you may know the ptg happend last week an done of hte topic raised there was a know limitation in devstack where GLOBAL_VENV=True does not work on centos/fedora derived distros.
while i generally dont use centos/fedora derived distros for my daily work i have been using devstack for over 10 years at this point so when im told it broken i ocationlly will go fix it. In this case the issue is not with devstack (it often isnt) and is actully in our collective reliance on a deprecated functionality and how we package openstack today.
Back story, for better or worse when openstack was created the landscape of python packaging was significantly different then it is today. To help corodinate our dependcies the openstack comunity went all in on requirements.txt and developed upper-constraits to manage our requirements and developed PBR (python build Reasonableness). both of those approches have served us well and likely will continue to do so for some time. Since then pyproject.toml has started to gain popularity and pep-517 (A build-system independent format for source trees) has been adotpted but so far openstack as a comunity has not embraced those changes. (although pbr already supprot pep-517 :) ). Until now this has not been a problem however with recent release of pip things are now breaking.
Problem Context:
- openstack does not provide pyporject.toml files
- openstack project configure setuptools to use pbr via setup.py
- setuptools support generating scripts form entry points(console_scripts) which we use for project binaries( nova-
compute, neutron-server, ...)
- openstack api services use a pbr extension know as wsgi_scripts which adds a similar functionality for generating
wsgi application mains file
- devstack due to coming changes in distro to block "sudo pip install" now installs openstack in a single by default on
debian distros. on centos/fedora distros it currently almost functional (but not).
- devstack installs in editable mode because that is how most developers use devstack for developemnt
What changed:
- pip 20.2 deprecated support for falling back to calling setup.py when pyproject.toml is not present
- https://pip.pypa.io/en/stable/news/#v20-2
- https://github.com/pypa/pip/issues/8368
- at this point when pyproject.yaml is not called pip calls setup.py install [-e] <path to repo or package name>
- setup.py invokes pbr to generate wsgi_scripts and other files
- in pip 23.1 the fallback was removed https://pip.pypa.io/en/stable/news/#v23-1
- pip now builds a temp local wheel instead of calling setup.py install when pyproject.toml is not found
- in editable mode (-e) the default way the wheel is built does not invoke pbr properly to generate the wsgi files
- as a result the wsgi files are not installed to the venv bin dir and this causes devstack to fail to start keystone
(or any other wsgi api)
The fix, there are a few ways to approch this:
- clamp pip (https://review.opendev.org/c/openstack/devstack/+/898845) this is a terible idea and it breaks debian
- clamping pip below 23.1 works on centos for now however OVS on debian already requires pep 517 for installing
- as such when that version of ovs (or other projects start enforcing that) hits centos it will break
- add a minimal pyproject.toml to all openstack project
- example for keystone https://review.opendev.org/c/openstack/keystone/+/899519
- this example jsut adds the minium pyproject.toml to enable pbr to be used as the build system
- it does not remove supprot for setup.py but it will not be used by default going forward whit new version of pip
- all config is still in setup.cfg
- add pyproject.toml support but remove setup.py support https://review.opendev.org/c/opendev/bindep/+/816741
- this goes one step futrue and actuly nulls out setup.py
- we could take this approach if we want to but its not required.
The reason for this email is to get agreement on how to support pip 23.1+ My proposal would be to add pyproject.toml with the minimal config required to enable pip 23.2 but not drop the setup.py support in this cycle. i would suggest that we can deprecate installing via setup.py in caracal if that is desirable but not make that change until the next slurp to give time to projects and packages to catch up.
if there are no objections to that i would like to ask what is the preferd way to create and submit the patches for the minimal pyproject.toml
[build-system] requires = ["pbr>=5.7.0", "setuptools>=36.6.0", "wheel"] build-backend = "pbr.build"i can propose patches to the main project deployed by devstack by default. i.e. nova/neutron ectra but it might be better if someone form the core teams of each project could take on that task and chasing the reviews. if someone has a script to generate a patch for a set of repos that just add the above pyporject.toml then we can use that to keep a consistent topic/commit message across all patches.
my proposal for testing this is two fold. in ci we can test the patches are functional by using a DNM patch to devstack to force enable the gloal venv on centos and depend on the set of patches, i will modify https://review.opendev.org/c/openstack/devstack/+/898845 to do that
locally we can test that the patch is functional by doing the following substituting keystone for the relevant project.
git clone https://opendev.org/openstack/keystone cd keystone python3 -m venv .venv . .venv/bin/activate python3 -m pip install -U pip python3 -m pip install -e . ls .venv/bin/keystone*the ls will not contain the wsgi script with the addition of the pyproject.toml it should.
on debian sid i can reproduce the same issue the problem we are seeing on centos 9 now will start impacting other distos eventually so its good to fix this now.
if i start proposing this to glance/nova/neutron/cinder/swift/horizon/placement (to get a default devstack working) can i get cores to review? can cores form each project nominate peopel to review or volenteer to do this work. i have created https://etherpad.opendev.org/p/pep-517-and-pip-23 to track this work
i have some other work that i think we can do in parallel like addign pyporject.toml support to the pti requirements if we go this way but that i think we can discuss on a governacne patch to updated it.
anyway this is a lot to digest so feedback is welcome. if someone else would like to drive this that is also welcome (i.e. tc/release team)
regards sean.
On 2023-10-31 15:27:19 +0000 (+0000), Stephen Finucane wrote: [...]
adding a 'pyproject.toml' file is enough to trigger isolated builds by default.
[...]
Note that with the latest version of pip, that ship has sailed. It now invents a fallback pyproject.toml internally if the project doesn't supply one of its own.
On Tue, 2023-10-31 at 15:34 +0000, Jeremy Stanley wrote:
On 2023-10-31 15:27:19 +0000 (+0000), Stephen Finucane wrote: [...]
adding a 'pyproject.toml' file is enough to trigger isolated builds by default.
[...]
Note that with the latest version of pip, that ship has sailed. It now invents a fallback pyproject.toml internally if the project doesn't supply one of its own.
so there wasnt so i just pushed https://review.opendev.org/c/openstack/nova/+/899753
if i do ``` python3 -m venv .venv . .venv/bin/activate python3 -m pip install -U pip python3 -m pip install -e . ls .venv/bin/nova-* ``` the wsgi and console scripts all seam to be there
~/repos/nova-pip on pip-23.1-support [$] via 🐍 v3.11.6 (.venv) [21:27:22]❯ ls .venv/bin/nova-* .venv/bin/nova-api .venv/bin/nova-compute .venv/bin/nova-novncproxy .venv/bin/nova-scheduler .venv/bin/nova-api-metadata .venv/bin/nova-conductor .venv/bin/nova-policy .venv/bin/nova-serialproxy .venv/bin/nova-api-os-compute .venv/bin/nova-manage .venv/bin/nova-rootwrap .venv/bin/nova- spicehtml5proxy .venv/bin/nova-api-wsgi .venv/bin/nova-metadata-wsgi .venv/bin/nova-rootwrap-daemon .venv/bin/nova-status
tox -e py3
give thsi warning
.pkg: package config for all-docs, api-guide, api-ref, api-samples, autopep8, bandit, cover, debug, docs, fast8, functional, functional-py311, functional-without-sample-db-tests, genconfig, genpolicy, mypy, pdf-docs, pep8, py3, py311, releasenotes, unit, validate-backport, venv is editable, however the build backend pbr.build does not support PEP-660, falling back to editable-legacy - change your configuration to it
id actully start rungin the unit tests however.
i dint let it finsinish but i execpt it to pass since they were all passing.
so we might need to figure out what PEP-660 is and add support to that in pbr in the future but for now it seams ot be functional
On Tue, 2023-10-31 at 21:31 +0000, smooney@redhat.com wrote:
On Tue, 2023-10-31 at 15:34 +0000, Jeremy Stanley wrote:
On 2023-10-31 15:27:19 +0000 (+0000), Stephen Finucane wrote: [...]
adding a 'pyproject.toml' file is enough to trigger isolated builds by default.
[...]
Note that with the latest version of pip, that ship has sailed. It now invents a fallback pyproject.toml internally if the project doesn't supply one of its own.
so there wasnt so i just pushed https://review.opendev.org/c/openstack/nova/+/899753
if i do
python3 -m venv .venv . .venv/bin/activate python3 -m pip install -U pip python3 -m pip install -e . ls .venv/bin/nova-*the wsgi and console scripts all seam to be there
~/repos/nova-pip on pip-23.1-support [$] via 🐍 v3.11.6 (.venv) [21:27:22]❯ ls .venv/bin/nova-* .venv/bin/nova-api .venv/bin/nova-compute .venv/bin/nova-novncproxy .venv/bin/nova-scheduler .venv/bin/nova-api-metadata .venv/bin/nova-conductor .venv/bin/nova-policy .venv/bin/nova- serialproxy .venv/bin/nova-api-os-compute .venv/bin/nova-manage .venv/bin/nova-rootwrap .venv/bin/nova- spicehtml5proxy .venv/bin/nova-api-wsgi .venv/bin/nova-metadata-wsgi .venv/bin/nova-rootwrap-daemon .venv/bin/nova-status
tox -e py3
give thsi warning
.pkg: package config for all-docs, api-guide, api-ref, api-samples, autopep8, bandit, cover, debug, docs, fast8, functional, functional-py311, functional-without-sample-db-tests, genconfig, genpolicy, mypy, pdf-docs, pep8, py3, py311, releasenotes, unit, validate-backport, venv is editable, however the build backend pbr.build does not support PEP-660, falling back to editable-legacy - change your configuration to it
id actully start rungin the unit tests however.
i dint let it finsinish but i execpt it to pass since they were all passing.
so we might need to figure out what PEP-660 is and add support to that in pbr in the future but for now it seams ot be functional
oh pep 660 is epxlictly supprot for editbale isntalls i.e. pip install -e
https://peps.python.org/pep-0660/
the unit test passed by the way.
====== Totals ====== Ran: 16864 tests in 184.3535 sec. - Passed: 16804 - Skipped: 59 - Expected Fail: 1 - Unexpected Success: 0 - Failed: 0 Sum of execute time for each test: 2764.2735 sec.
so i think that is enogh of a poc to show it works
ill update the etherpath with the link and update the devstack patch tomorrow to test this with depend on. that will give use some integration level testing.
So I have some questions here
1. I actually assume, that this is also affecting stable branches in a way as well (or well, it potentially can), so I assume we also should clamp pip<23.1 there anyway? 2. How that's gonna work if at any point of time someone would need to constrain setuptools or wheels version? As from what I can recall, if no version is specified in project.toml it will always just install latest, with kinda no way to override that for the ones who installs the package, which might result in it being uninstallable on some stable branch with some time due to release of new setuptools that, for example, removes support of setup.cfg As no later then last year there was an issue with gnocchi [1], so all versions containing pyproject.toml got uninstallable until fix landed and was backported. This actually a thing that concerns me most with pyproject.toml, that if it's under maintained, or they're technical debts or any usage of deprecated methods, there are kinda no way for end-users to make overrides of requires to use specific or lower version of wheels, to make package installable until an upstream fix will land. Or, I just haven't found the way how to do that back in the days...
[1] https://github.com/gnocchixyz/gnocchi/issues/1304
On Tue, Oct 31, 2023, 22:44 smooney@redhat.com wrote:
On Tue, 2023-10-31 at 21:31 +0000, smooney@redhat.com wrote:
On Tue, 2023-10-31 at 15:34 +0000, Jeremy Stanley wrote:
On 2023-10-31 15:27:19 +0000 (+0000), Stephen Finucane wrote: [...]
adding a 'pyproject.toml' file is enough to trigger isolated builds by default.
[...]
Note that with the latest version of pip, that ship has sailed. It now invents a fallback pyproject.toml internally if the project doesn't supply one of its own.
so there wasnt so i just pushed
https://review.opendev.org/c/openstack/nova/+/899753
if i do
python3 -m venv .venv . .venv/bin/activate python3 -m pip install -U pip python3 -m pip install -e . ls .venv/bin/nova-*the wsgi and console scripts all seam to be there
~/repos/nova-pip on pip-23.1-support [$] via 🐍 v3.11.6 (.venv) [21:27:22]❯ ls .venv/bin/nova-* .venv/bin/nova-api .venv/bin/nova-compute
.venv/bin/nova-novncproxy .venv/bin/nova-scheduler
.venv/bin/nova-api-metadata .venv/bin/nova-conductor
.venv/bin/nova-policy .venv/bin/nova-
serialproxy .venv/bin/nova-api-os-compute .venv/bin/nova-manage
.venv/bin/nova-rootwrap .venv/bin/nova-
spicehtml5proxy .venv/bin/nova-api-wsgi .venv/bin/nova-metadata-wsgi
.venv/bin/nova-rootwrap-daemon .venv/bin/nova-status
tox -e py3
give thsi warning
.pkg: package config for all-docs, api-guide, api-ref, api-samples,
autopep8, bandit, cover, debug, docs, fast8,
functional, functional-py311, functional-without-sample-db-tests,
genconfig, genpolicy, mypy, pdf-docs, pep8, py3,
py311, releasenotes, unit, validate-backport, venv is editable, however
the build backend pbr.build does not support
PEP-660, falling back to editable-legacy - change your configuration to
it
id actully start rungin the unit tests however.
i dint let it finsinish but i execpt it to pass since they were all
passing.
so we might need to figure out what PEP-660 is and add support to that
in pbr in the future but for now it
seams ot be functional
oh pep 660 is epxlictly supprot for editbale isntalls i.e. pip install -e
https://peps.python.org/pep-0660/
the unit test passed by the way.
====== Totals ====== Ran: 16864 tests in 184.3535 sec.
- Passed: 16804
- Skipped: 59
- Expected Fail: 1
- Unexpected Success: 0
- Failed: 0
Sum of execute time for each test: 2764.2735 sec.
so i think that is enogh of a poc to show it works
ill update the etherpath with the link and update the devstack patch tomorrow to test this with depend on. that will give use some integration level testing.
On 2023-11-01 05:28:40 +0000 (+0000), Dmitriy Rabotyagov wrote:
So I have some questions here
- I actually assume, that this is also affecting stable branches
in a way as well (or well, it potentially can), so I assume we also should clamp pip<23.1 there anyway?
Inasmuch as this is possible, I suppose that's an easier way around the problem there.
- How that's gonna work if at any point of time someone would
need to constrain setuptools or wheels version?
[...]
Keep in mind that the way PEP 517 works is that an ephemeral build venv is created with just the specific packages that we would have traditionally referred to as setup_requires, and that is used to create a wheel from a retrieved sdist or local source tree. You can specify upper version bounds for things in pyproject.toml, as long as the full set of build requirements is still solvable by pip's resolver. Those can be an entirely disjoint set compared to the packages needed in the environment where the resulting wheel is installed.
Also, if you're installing from a wheel instead of sdist or local source tree, then none of this even matters since there is no build step on the user's system; pip simply unpacks the wheel into the requested environment.
On Wed, Nov 1, 2023, at 7:34 AM, Jeremy Stanley wrote:
On 2023-11-01 05:28:40 +0000 (+0000), Dmitriy Rabotyagov wrote:
So I have some questions here
- I actually assume, that this is also affecting stable branches
in a way as well (or well, it potentially can), so I assume we also should clamp pip<23.1 there anyway?
Inasmuch as this is possible, I suppose that's an easier way around the problem there.
- How that's gonna work if at any point of time someone would
need to constrain setuptools or wheels version?
[...]
Keep in mind that the way PEP 517 works is that an ephemeral build venv is created with just the specific packages that we would have traditionally referred to as setup_requires, and that is used to create a wheel from a retrieved sdist or local source tree. You can specify upper version bounds for things in pyproject.toml, as long as the full set of build requirements is still solvable by pip's resolver. Those can be an entirely disjoint set compared to the packages needed in the environment where the resulting wheel is installed.
It is also an improvement over the prior situation. Previously, you had very little control over the version of setuptools used to build or install your project. It was whatever already existed on the system as setuptools bootstrapping different versions of itself was/is not very reliable. More recently pip switched to using a default pyproject.toml that also does not cap or constraint setuptools; again, not much control here.
By providing a pyproject.toml you can control all of this as long as the dep solver can resolve this. Yes, you might get it wrong eventually and need to make an update. But now, unlike before, you can actually do something about that and update your pyproject.toml file.
On Tue, 2023-10-31 at 14:46 +0000, smooney@redhat.com wrote:
hi folks,
TL;DR
this is a long email so the tl;dr is we should add pyproject.toml
[build-system] requires = ["pbr>=5.7.0", "setuptools>=36.6.0", "wheel"] build-backend = "pbr.build"to all openstack projects to supprot pip 23.1+
A follow-up tl;dr: PEP-660 support has now merged to pbr, so you'll want to use the latest and greatest pbr release, 6.0.0, to get this. You also don't need to specify the 'wheel' dependency [1]. That means you'll want a 'pyproject.toml' like so:
[build-system] requires = ["pbr>6.0.0", "setuptools>=64.0.0"] build-backend = "pbr.build"
If you don't use pbr 6.0.0, you're likely to see the following error pop up in your Python 3.9 test runs:
tox.tox_env.python.virtual_env.package.pyproject.BuildEditableNotSupportedError
I haven't investigated this or figured out why this only happens on Python 3.9 yet. If someone can, please post your findings here.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/pbr/+/831215
Long version
As some of you may know the ptg happend last week an done of hte topic raised there was a know limitation in devstack where GLOBAL_VENV=True does not work on centos/fedora derived distros.
while i generally dont use centos/fedora derived distros for my daily work i have been using devstack for over 10 years at this point so when im told it broken i ocationlly will go fix it. In this case the issue is not with devstack (it often isnt) and is actully in our collective reliance on a deprecated functionality and how we package openstack today.
Back story, for better or worse when openstack was created the landscape of python packaging was significantly different then it is today. To help corodinate our dependcies the openstack comunity went all in on requirements.txt and developed upper-constraits to manage our requirements and developed PBR (python build Reasonableness). both of those approches have served us well and likely will continue to do so for some time. Since then pyproject.toml has started to gain popularity and pep-517 (A build-system independent format for source trees) has been adotpted but so far openstack as a comunity has not embraced those changes. (although pbr already supprot pep-517 :) ). Until now this has not been a problem however with recent release of pip things are now breaking.
Problem Context:
- openstack does not provide pyporject.toml files
- openstack project configure setuptools to use pbr via setup.py
- setuptools support generating scripts form entry points(console_scripts) which we use for project binaries( nova-
compute, neutron-server, ...)
- openstack api services use a pbr extension know as wsgi_scripts which adds a similar functionality for generating
wsgi application mains file
- devstack due to coming changes in distro to block "sudo pip install" now installs openstack in a single by default on
debian distros. on centos/fedora distros it currently almost functional (but not).
- devstack installs in editable mode because that is how most developers use devstack for developemnt
What changed:
- pip 20.2 deprecated support for falling back to calling setup.py when pyproject.toml is not present
- https://pip.pypa.io/en/stable/news/#v20-2
- https://github.com/pypa/pip/issues/8368
- at this point when pyproject.yaml is not called pip calls setup.py install [-e] <path to repo or package name>
- setup.py invokes pbr to generate wsgi_scripts and other files
- in pip 23.1 the fallback was removed https://pip.pypa.io/en/stable/news/#v23-1
- pip now builds a temp local wheel instead of calling setup.py install when pyproject.toml is not found
- in editable mode (-e) the default way the wheel is built does not invoke pbr properly to generate the wsgi files
- as a result the wsgi files are not installed to the venv bin dir and this causes devstack to fail to start keystone
(or any other wsgi api)
The fix, there are a few ways to approch this:
- clamp pip (https://review.opendev.org/c/openstack/devstack/+/898845) this is a terible idea and it breaks debian
- clamping pip below 23.1 works on centos for now however OVS on debian already requires pep 517 for installing
- as such when that version of ovs (or other projects start enforcing that) hits centos it will break
- add a minimal pyproject.toml to all openstack project
- example for keystone https://review.opendev.org/c/openstack/keystone/+/899519
- this example jsut adds the minium pyproject.toml to enable pbr to be used as the build system
- it does not remove supprot for setup.py but it will not be used by default going forward whit new version of pip
- all config is still in setup.cfg
- add pyproject.toml support but remove setup.py support https://review.opendev.org/c/opendev/bindep/+/816741
- this goes one step futrue and actuly nulls out setup.py
- we could take this approach if we want to but its not required.
The reason for this email is to get agreement on how to support pip 23.1+ My proposal would be to add pyproject.toml with the minimal config required to enable pip 23.2 but not drop the setup.py support in this cycle. i would suggest that we can deprecate installing via setup.py in caracal if that is desirable but not make that change until the next slurp to give time to projects and packages to catch up.
if there are no objections to that i would like to ask what is the preferd way to create and submit the patches for the minimal pyproject.toml
[build-system] requires = ["pbr>=5.7.0", "setuptools>=36.6.0", "wheel"] build-backend = "pbr.build"i can propose patches to the main project deployed by devstack by default. i.e. nova/neutron ectra but it might be better if someone form the core teams of each project could take on that task and chasing the reviews. if someone has a script to generate a patch for a set of repos that just add the above pyporject.toml then we can use that to keep a consistent topic/commit message across all patches.
my proposal for testing this is two fold. in ci we can test the patches are functional by using a DNM patch to devstack to force enable the gloal venv on centos and depend on the set of patches, i will modify https://review.opendev.org/c/openstack/devstack/+/898845 to do that
locally we can test that the patch is functional by doing the following substituting keystone for the relevant project.
git clone https://opendev.org/openstack/keystone cd keystone python3 -m venv .venv . .venv/bin/activate python3 -m pip install -U pip python3 -m pip install -e . ls .venv/bin/keystone*the ls will not contain the wsgi script with the addition of the pyproject.toml it should.
on debian sid i can reproduce the same issue the problem we are seeing on centos 9 now will start impacting other distos eventually so its good to fix this now.
if i start proposing this to glance/nova/neutron/cinder/swift/horizon/placement (to get a default devstack working) can i get cores to review? can cores form each project nominate peopel to review or volenteer to do this work. i have created https://etherpad.opendev.org/p/pep-517-and-pip-23 to track this work
i have some other work that i think we can do in parallel like addign pyporject.toml support to the pti requirements if we go this way but that i think we can discuss on a governacne patch to updated it.
anyway this is a lot to digest so feedback is welcome. if someone else would like to drive this that is also welcome (i.e. tc/release team)
regards sean.
Hey all,
Are we sure this solution works? I am still not having any wsgi scripts in my bin/ folder, even with the pyproject.toml file...
On a fresh ubuntu 22.04 (same on deb12)
sudo apt-get update sudo apt install python3.10-venv build-essential git clone https://opendev.org/openstack/keystone cd keystone/ grep dpkg bindep.txt | awk '{print $1}' | xargs sudo apt-get install -y git fetch https://review.opendev.org/openstack/keystone refs/changes/19/899519/4 && git checkout FETCH_HEAD python3 -m venv .venv . .venv/bin/activate python3 -m pip install -U pip python3 -m pip install -e . ls .venv/bin/keystone-* .venv/bin/keystone-manage .venv/bin/keystone-status
Cheers, Arnaud
On 08.11.23 - 11:13, Stephen Finucane wrote:
On Tue, 2023-10-31 at 14:46 +0000, smooney@redhat.com wrote:
hi folks,
TL;DR
this is a long email so the tl;dr is we should add pyproject.toml
[build-system] requires = ["pbr>=5.7.0", "setuptools>=36.6.0", "wheel"] build-backend = "pbr.build"to all openstack projects to supprot pip 23.1+
A follow-up tl;dr: PEP-660 support has now merged to pbr, so you'll want to use the latest and greatest pbr release, 6.0.0, to get this. You also don't need to specify the 'wheel' dependency [1]. That means you'll want a 'pyproject.toml' like so:
[build-system] requires = ["pbr>6.0.0", "setuptools>=64.0.0"] build-backend = "pbr.build"If you don't use pbr 6.0.0, you're likely to see the following error pop up in your Python 3.9 test runs:
tox.tox_env.python.virtual_env.package.pyproject.BuildEditableNotSupportedError
I haven't investigated this or figured out why this only happens on Python 3.9 yet. If someone can, please post your findings here.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/pbr/+/831215
Long version
As some of you may know the ptg happend last week an done of hte topic raised there was a know limitation in devstack where GLOBAL_VENV=True does not work on centos/fedora derived distros.
while i generally dont use centos/fedora derived distros for my daily work i have been using devstack for over 10 years at this point so when im told it broken i ocationlly will go fix it. In this case the issue is not with devstack (it often isnt) and is actully in our collective reliance on a deprecated functionality and how we package openstack today.
Back story, for better or worse when openstack was created the landscape of python packaging was significantly different then it is today. To help corodinate our dependcies the openstack comunity went all in on requirements.txt and developed upper-constraits to manage our requirements and developed PBR (python build Reasonableness). both of those approches have served us well and likely will continue to do so for some time. Since then pyproject.toml has started to gain popularity and pep-517 (A build-system independent format for source trees) has been adotpted but so far openstack as a comunity has not embraced those changes. (although pbr already supprot pep-517 :) ). Until now this has not been a problem however with recent release of pip things are now breaking.
Problem Context:
- openstack does not provide pyporject.toml files
- openstack project configure setuptools to use pbr via setup.py
- setuptools support generating scripts form entry points(console_scripts) which we use for project binaries( nova-
compute, neutron-server, ...)
- openstack api services use a pbr extension know as wsgi_scripts which adds a similar functionality for generating
wsgi application mains file
- devstack due to coming changes in distro to block "sudo pip install" now installs openstack in a single by default on
debian distros. on centos/fedora distros it currently almost functional (but not).
- devstack installs in editable mode because that is how most developers use devstack for developemnt
What changed:
- pip 20.2 deprecated support for falling back to calling setup.py when pyproject.toml is not present
- https://pip.pypa.io/en/stable/news/#v20-2
- https://github.com/pypa/pip/issues/8368
- at this point when pyproject.yaml is not called pip calls setup.py install [-e] <path to repo or package name>
- setup.py invokes pbr to generate wsgi_scripts and other files
- in pip 23.1 the fallback was removed https://pip.pypa.io/en/stable/news/#v23-1
- pip now builds a temp local wheel instead of calling setup.py install when pyproject.toml is not found
- in editable mode (-e) the default way the wheel is built does not invoke pbr properly to generate the wsgi files
- as a result the wsgi files are not installed to the venv bin dir and this causes devstack to fail to start keystone
(or any other wsgi api)
The fix, there are a few ways to approch this:
- clamp pip (https://review.opendev.org/c/openstack/devstack/+/898845) this is a terible idea and it breaks debian
- clamping pip below 23.1 works on centos for now however OVS on debian already requires pep 517 for installing
- as such when that version of ovs (or other projects start enforcing that) hits centos it will break
- add a minimal pyproject.toml to all openstack project
- example for keystone https://review.opendev.org/c/openstack/keystone/+/899519
- this example jsut adds the minium pyproject.toml to enable pbr to be used as the build system
- it does not remove supprot for setup.py but it will not be used by default going forward whit new version of pip
- all config is still in setup.cfg
- add pyproject.toml support but remove setup.py support https://review.opendev.org/c/opendev/bindep/+/816741
- this goes one step futrue and actuly nulls out setup.py
- we could take this approach if we want to but its not required.
The reason for this email is to get agreement on how to support pip 23.1+ My proposal would be to add pyproject.toml with the minimal config required to enable pip 23.2 but not drop the setup.py support in this cycle. i would suggest that we can deprecate installing via setup.py in caracal if that is desirable but not make that change until the next slurp to give time to projects and packages to catch up.
if there are no objections to that i would like to ask what is the preferd way to create and submit the patches for the minimal pyproject.toml
[build-system] requires = ["pbr>=5.7.0", "setuptools>=36.6.0", "wheel"] build-backend = "pbr.build"i can propose patches to the main project deployed by devstack by default. i.e. nova/neutron ectra but it might be better if someone form the core teams of each project could take on that task and chasing the reviews. if someone has a script to generate a patch for a set of repos that just add the above pyporject.toml then we can use that to keep a consistent topic/commit message across all patches.
my proposal for testing this is two fold. in ci we can test the patches are functional by using a DNM patch to devstack to force enable the gloal venv on centos and depend on the set of patches, i will modify https://review.opendev.org/c/openstack/devstack/+/898845 to do that
locally we can test that the patch is functional by doing the following substituting keystone for the relevant project.
git clone https://opendev.org/openstack/keystone cd keystone python3 -m venv .venv . .venv/bin/activate python3 -m pip install -U pip python3 -m pip install -e . ls .venv/bin/keystone*the ls will not contain the wsgi script with the addition of the pyproject.toml it should.
on debian sid i can reproduce the same issue the problem we are seeing on centos 9 now will start impacting other distos eventually so its good to fix this now.
if i start proposing this to glance/nova/neutron/cinder/swift/horizon/placement (to get a default devstack working) can i get cores to review? can cores form each project nominate peopel to review or volenteer to do this work. i have created https://etherpad.opendev.org/p/pep-517-and-pip-23 to track this work
i have some other work that i think we can do in parallel like addign pyporject.toml support to the pti requirements if we go this way but that i think we can discuss on a governacne patch to updated it.
anyway this is a lot to digest so feedback is welcome. if someone else would like to drive this that is also welcome (i.e. tc/release team)
regards sean.
On 2023-11-08 23:11:54 +0000 (+0000), Arnaud Morin wrote:
Are we sure this solution works? I am still not having any wsgi scripts in my bin/ folder, even with the pyproject.toml file...
[...]
For editable installs (pip install -e ...) you need the PEP 660 support in PBR 6.0.0, which has only been out for a day now.
I was thinking the same, but this is what I have: $ pip freeze |grep pbr pbr==6.0.0
On 08.11.23 - 23:28, Jeremy Stanley wrote:
On 2023-11-08 23:11:54 +0000 (+0000), Arnaud Morin wrote:
Are we sure this solution works? I am still not having any wsgi scripts in my bin/ folder, even with the pyproject.toml file...
[...]
For editable installs (pip install -e ...) you need the PEP 660 support in PBR 6.0.0, which has only been out for a day now. -- Jeremy Stanley
On Thu, 2023-11-09 at 07:14 +0000, Arnaud Morin wrote:
I was thinking the same, but this is what I have: $ pip freeze |grep pbr pbr==6.0.0
Yes, it appears this *does not* work unfortunately. It looks like we've got even more work to do here. sean-k-mooney and I have been discussing this and they've done some work tracing the code paths. At this point in time, it's looking like we may need to implement our own PEP-517/660 build backend code rather than reusing setuptools' since setuptools doesn't provide any hook points that we can use.
Sean and I have revived a discussion I had previously started on discuss.python.org [1]. One can hope that something will come out of that but I'm pretty doubtful at this moment in time.
Stephen
[1] https://discuss.python.org/t/adding-support-for-wsgi-scripts-entrypoint/3090...
On 08.11.23 - 23:28, Jeremy Stanley wrote:
On 2023-11-08 23:11:54 +0000 (+0000), Arnaud Morin wrote:
Are we sure this solution works? I am still not having any wsgi scripts in my bin/ folder, even with the pyproject.toml file...
[...]
For editable installs (pip install -e ...) you need the PEP 660 support in PBR 6.0.0, which has only been out for a day now. -- Jeremy Stanley
On Thu, 2023-11-09 at 07:14 +0000, Arnaud Morin wrote:
I was thinking the same, but this is what I have: $ pip freeze |grep pbr pbr==6.0.0
so... that is not enough it turns out that pep 660 explcitly does not cover datafile or sciprt it only covers pure python libs
so pbr now has support for pep-660 and editable wheels. that pep does not support our use of a pbr/setupppols/distutils custom entrypoints
so in editbale mode nothing invokes the logic in pbr to genergate the wsgi scripts
i was talkign to stephenfin about his this morning an i think the best approch will be to stop using wsgi_script in openstack in general we can support both as a transition period. stephen is workign on a very small poc patch to export our wsgi scripts as console_scripts for nova and we can see if that work with devstack as we expect.
this was aready done for gnocchi https://github.com/gnocchixyz/gnocchi/commit/3f45e24803f4d6e88bc1f4606310585... if you want to see what it looks like but the nova version shoudl be closer to what we woudl expect others to do.
i dont really see a way for use to continue to support wsgi_scripts via pbr and it actully might make sense longterm to just move to using setuptools_scm instead as our packaging system.
i raised my fustration at the fact that pep-660 has no way to enable this type of extention in https://discuss.python.org/t/adding-support-for-wsgi-scripts-entrypoint/3090...
if the nova poc works and we agree on that direction i can try and update the patches i submitted do the same for other project if their maintainers done have time to take them over but my time is also limited.
On 08.11.23 - 23:28, Jeremy Stanley wrote:
On 2023-11-08 23:11:54 +0000 (+0000), Arnaud Morin wrote:
Are we sure this solution works? I am still not having any wsgi scripts in my bin/ folder, even with the pyproject.toml file...
[...]
For editable installs (pip install -e ...) you need the PEP 660 support in PBR 6.0.0, which has only been out for a day now. -- Jeremy Stanley
Here is what I proposed for mistral CI until we managed a better or global option:
https://review.opendev.org/c/openstack/mistral/+/900566
Cheers,
On 09.11.23 - 13:31, smooney@redhat.com wrote:
On Thu, 2023-11-09 at 07:14 +0000, Arnaud Morin wrote:
I was thinking the same, but this is what I have: $ pip freeze |grep pbr pbr==6.0.0
so... that is not enough it turns out that pep 660 explcitly does not cover datafile or sciprt it only covers pure python libs
so pbr now has support for pep-660 and editable wheels. that pep does not support our use of a pbr/setupppols/distutils custom entrypoints
so in editbale mode nothing invokes the logic in pbr to genergate the wsgi scripts
i was talkign to stephenfin about his this morning an i think the best approch will be to stop using wsgi_script in openstack in general we can support both as a transition period. stephen is workign on a very small poc patch to export our wsgi scripts as console_scripts for nova and we can see if that work with devstack as we expect.
this was aready done for gnocchi https://github.com/gnocchixyz/gnocchi/commit/3f45e24803f4d6e88bc1f4606310585... if you want to see what it looks like but the nova version shoudl be closer to what we woudl expect others to do.
i dont really see a way for use to continue to support wsgi_scripts via pbr and it actully might make sense longterm to just move to using setuptools_scm instead as our packaging system.
i raised my fustration at the fact that pep-660 has no way to enable this type of extention in https://discuss.python.org/t/adding-support-for-wsgi-scripts-entrypoint/3090...
if the nova poc works and we agree on that direction i can try and update the patches i submitted do the same for other project if their maintainers done have time to take them over but my time is also limited.
On 08.11.23 - 23:28, Jeremy Stanley wrote:
On 2023-11-08 23:11:54 +0000 (+0000), Arnaud Morin wrote:
Are we sure this solution works? I am still not having any wsgi scripts in my bin/ folder, even with the pyproject.toml file...
[...]
For editable installs (pip install -e ...) you need the PEP 660 support in PBR 6.0.0, which has only been out for a day now. -- Jeremy Stanley
Sorry for the stupid question, but how ones now should use mistral-api with uwsgi?
So given that Mistral is installed in venv, should it be configured to be smth like /opt/virtualenvs/mistral-17.0.0/lib/pythonX.YY/site-packages/mistral/api/wsgi.py ?
Why I am asking, is basically because MISTRAL_ENV_DIR is not that straightforward to define outside of the devstack, especially the part with the python version, given that venv can be created with non-default python for the system (ie, one installed with pyenv). So now configuring uwsgi becomes way more complex from regular user perspective, unless I'm missing smth.
On Sun, Nov 12, 2023, 11:11 Arnaud Morin arnaud.morin@gmail.com wrote:
Here is what I proposed for mistral CI until we managed a better or global option:
https://review.opendev.org/c/openstack/mistral/+/900566
Cheers,
On 09.11.23 - 13:31, smooney@redhat.com wrote:
On Thu, 2023-11-09 at 07:14 +0000, Arnaud Morin wrote:
I was thinking the same, but this is what I have: $ pip freeze |grep pbr pbr==6.0.0
so... that is not enough it turns out that pep 660 explcitly does not cover datafile or sciprt it
only covers pure python libs
so pbr now has support for pep-660 and editable wheels. that pep does not support our use of a pbr/setupppols/distutils custom
entrypoints
so in editbale mode nothing invokes the logic in pbr to genergate the
wsgi scripts
i was talkign to stephenfin about his this morning an i think the best
approch will be to stop using
wsgi_script in openstack in general we can support both as a transition
period.
stephen is workign on a very small poc patch to export our wsgi scripts
as console_scripts for nova
and we can see if that work with devstack as we expect.
this was aready done for gnocchi
https://github.com/gnocchixyz/gnocchi/commit/3f45e24803f4d6e88bc1f4606310585...
if you want to see what it looks like but the nova version shoudl be
closer to what we woudl expect others to do.
i dont really see a way for use to continue to support wsgi_scripts via
pbr and it actully might
make sense longterm to just move to using setuptools_scm instead as our
packaging system.
i raised my fustration at the fact that pep-660 has no way to enable
this type of extention
in
https://discuss.python.org/t/adding-support-for-wsgi-scripts-entrypoint/3090...
if the nova poc works and we agree on that direction i can try and
update the patches i submitted
do the same for other project if their maintainers done have time to
take them over but my time
is also limited.
On 08.11.23 - 23:28, Jeremy Stanley wrote:
On 2023-11-08 23:11:54 +0000 (+0000), Arnaud Morin wrote:
Are we sure this solution works? I am still not having any wsgi scripts in my bin/ folder, even
with the
pyproject.toml file...
[...]
For editable installs (pip install -e ...) you need the PEP 660 support in PBR 6.0.0, which has only been out for a day now. -- Jeremy Stanley
Yes you have either to know where that file is or to copy it somewhere else.
Anyway, the thing is that you have to know where the venv is to execute it from the correct python home dir.
I am not sure this is a perfect solution but at least it unlock our ci until we figure something else.
Maybe we can switch the wsgi script to a console script instead, but as per my tests it needs a change in PBR (maybe I was not doing it right).
Le 12 novembre 2023 13:22:36 GMT+01:00, Dmitriy Rabotyagov noonedeadpunk@gmail.com a écrit :
Sorry for the stupid question, but how ones now should use mistral-api with uwsgi?
So given that Mistral is installed in venv, should it be configured to be smth like /opt/virtualenvs/mistral-17.0.0/lib/pythonX.YY/site-packages/mistral/api/wsgi.py ?
Why I am asking, is basically because MISTRAL_ENV_DIR is not that straightforward to define outside of the devstack, especially the part with the python version, given that venv can be created with non-default python for the system (ie, one installed with pyenv). So now configuring uwsgi becomes way more complex from regular user perspective, unless I'm missing smth.
On Sun, Nov 12, 2023, 11:11 Arnaud Morin arnaud.morin@gmail.com wrote:
Here is what I proposed for mistral CI until we managed a better or global option:
https://review.opendev.org/c/openstack/mistral/+/900566
Cheers,
On 09.11.23 - 13:31, smooney@redhat.com wrote:
On Thu, 2023-11-09 at 07:14 +0000, Arnaud Morin wrote:
I was thinking the same, but this is what I have: $ pip freeze |grep pbr pbr==6.0.0
so... that is not enough it turns out that pep 660 explcitly does not cover datafile or sciprt it
only covers pure python libs
so pbr now has support for pep-660 and editable wheels. that pep does not support our use of a pbr/setupppols/distutils custom
entrypoints
so in editbale mode nothing invokes the logic in pbr to genergate the
wsgi scripts
i was talkign to stephenfin about his this morning an i think the best
approch will be to stop using
wsgi_script in openstack in general we can support both as a transition
period.
stephen is workign on a very small poc patch to export our wsgi scripts
as console_scripts for nova
and we can see if that work with devstack as we expect.
this was aready done for gnocchi
https://github.com/gnocchixyz/gnocchi/commit/3f45e24803f4d6e88bc1f4606310585...
if you want to see what it looks like but the nova version shoudl be
closer to what we woudl expect others to do.
i dont really see a way for use to continue to support wsgi_scripts via
pbr and it actully might
make sense longterm to just move to using setuptools_scm instead as our
packaging system.
i raised my fustration at the fact that pep-660 has no way to enable
this type of extention
in
https://discuss.python.org/t/adding-support-for-wsgi-scripts-entrypoint/3090...
if the nova poc works and we agree on that direction i can try and
update the patches i submitted
do the same for other project if their maintainers done have time to
take them over but my time
is also limited.
On 08.11.23 - 23:28, Jeremy Stanley wrote:
On 2023-11-08 23:11:54 +0000 (+0000), Arnaud Morin wrote:
Are we sure this solution works? I am still not having any wsgi scripts in my bin/ folder, even
with the
pyproject.toml file...
[...]
For editable installs (pip install -e ...) you need the PEP 660 support in PBR 6.0.0, which has only been out for a day now. -- Jeremy Stanley
Well, as I said, bindir is smth you indeed know and can easily define knowing path to the venv. libdir is a different story, as you in fact don't know what is it going to be after running `python3 -m venv /opt/virtualenvs/mistral-17.0.0/` for example. As that path would depend on what python3 binary is actually representing. So afaik, the only good way then to identify libdir is to do smth like `/opt/virtualenvs/mistral-17.0.0/bin/python3 -c 'import mistral; print(mistral.__file__)'`, then get it's dirname and then append api/wsgi.py to the result. So as a regular user I would give up after not finding the binary for uwsgi and would just use eventlet server instead, to be frank, as you really need to be motivated enough to follow that path. And eventlet is not tested in devstack as assumption made that ppl should run things as wsgi app (and there's whole another thread for eventlet state and shape)...
On Sun, Nov 12, 2023, 18:50 Arnaud arnaud.morin@gmail.com wrote:
Yes you have either to know where that file is or to copy it somewhere else.
Anyway, the thing is that you have to know where the venv is to execute it from the correct python home dir.
I am not sure this is a perfect solution but at least it unlock our ci until we figure something else.
Maybe we can switch the wsgi script to a console script instead, but as per my tests it needs a change in PBR (maybe I was not doing it right).
Le 12 novembre 2023 13:22:36 GMT+01:00, Dmitriy Rabotyagov < noonedeadpunk@gmail.com> a écrit :
Sorry for the stupid question, but how ones now should use mistral-api with uwsgi?
So given that Mistral is installed in venv, should it be configured to be smth like /opt/virtualenvs/mistral-17.0.0/lib/pythonX.YY/site-packages/mistral/api/wsgi.py ?
Why I am asking, is basically because MISTRAL_ENV_DIR is not that straightforward to define outside of the devstack, especially the part with the python version, given that venv can be created with non-default python for the system (ie, one installed with pyenv). So now configuring uwsgi becomes way more complex from regular user perspective, unless I'm missing smth.
On Sun, Nov 12, 2023, 11:11 Arnaud Morin arnaud.morin@gmail.com wrote:
Here is what I proposed for mistral CI until we managed a better or global option:
https://review.opendev.org/c/openstack/mistral/+/900566
Cheers,
On 09.11.23 - 13:31, smooney@redhat.com wrote:
On Thu, 2023-11-09 at 07:14 +0000, Arnaud Morin wrote:
I was thinking the same, but this is what I have: $ pip freeze |grep pbr pbr==6.0.0
so... that is not enough it turns out that pep 660 explcitly does not cover datafile or sciprt
it only covers pure python libs
so pbr now has support for pep-660 and editable wheels. that pep does not support our use of a pbr/setupppols/distutils custom
entrypoints
so in editbale mode nothing invokes the logic in pbr to genergate the
wsgi scripts
i was talkign to stephenfin about his this morning an i think the best
approch will be to stop using
wsgi_script in openstack in general we can support both as a
transition period.
stephen is workign on a very small poc patch to export our wsgi
scripts as console_scripts for nova
and we can see if that work with devstack as we expect.
this was aready done for gnocchi
https://github.com/gnocchixyz/gnocchi/commit/3f45e24803f4d6e88bc1f4606310585...
if you want to see what it looks like but the nova version shoudl be
closer to what we woudl expect others to do.
i dont really see a way for use to continue to support wsgi_scripts
via pbr and it actully might
make sense longterm to just move to using setuptools_scm instead as
our packaging system.
i raised my fustration at the fact that pep-660 has no way to enable
this type of extention
in
https://discuss.python.org/t/adding-support-for-wsgi-scripts-entrypoint/3090...
if the nova poc works and we agree on that direction i can try and
update the patches i submitted
do the same for other project if their maintainers done have time to
take them over but my time
is also limited.
On 08.11.23 - 23:28, Jeremy Stanley wrote:
On 2023-11-08 23:11:54 +0000 (+0000), Arnaud Morin wrote: > Are we sure this solution works? > I am still not having any wsgi scripts in my bin/ folder, even
with the
> pyproject.toml file... [...]
For editable installs (pip install -e ...) you need the PEP 660 support in PBR 6.0.0, which has only been out for a day now. -- Jeremy Stanley
On Sun, 2023-11-12 at 20:42 +0100, Dmitriy Rabotyagov wrote:
Well, as I said, bindir is smth you indeed know and can easily define knowing path to the venv. libdir is a different story, as you in fact don't know what is it going to be after running `python3 -m venv /opt/virtualenvs/mistral-17.0.0/` for example. As that path would depend on what python3 binary is actually representing. So afaik, the only good way then to identify libdir is to do smth like `/opt/virtualenvs/mistral-17.0.0/bin/python3 -c 'import mistral; print(mistral.__file__)'`, then get it's dirname and then append api/wsgi.py to the result. So as a regular user I would give up after not finding the binary for uwsgi and would just use eventlet server instead, to be frank, as you really need to be motivated enough to follow that path. And eventlet is not tested in devstack as assumption made that ppl should run things as wsgi app (and there's whole another thread for eventlet state and shape)...
so i woudl prefer to hold off on making any change to any project until we figure this out propelry so i woudl suggest taht mistral not make any change for right now.
we have 2 option to maintain compaitbaliy 1 we can add a wsgi script to each repo and register that as a console scipt with the same name 2 i or someone else can modify pbr's build
i need to disable build isolation in the pip install line of this https://review.opendev.org/c/openstack/pbr/+/900728/1/pbr/tests/test_integra... but i have created a test that demonstrate that the wsgi files are missing right now https://github.com/openstack/pbr/blob/master/pbr/build.py#L82-L91 just calls setuptools to build the wheel instead we can take the wheel form setup tools and before we return a can generate the wsgi script and append them to the wheel produced by setup tools.
i have not fully figured out how to do that yet but we can levage the wheel spec to achive that normally our wsgi_scripts are added to the data dir https://peps.python.org/pep-0491/#the-data-directory any file added to wheel-*.data/scripts in the wheel are added to ${prefix}/bin when the wheel is installed. This is what we are using to package the wsgi_script and install it in a non editble wheel. when we do an editbale wheel build setup tools is not invokeing pbr in a way that causes it to be generated so we just need to fix that we can even leverage python #! Rewrite to have the installer (pip) ensure that uses the venv or system python automatically. https://peps.python.org/pep-0491/#recommended-installer-features
so if peole want to spend some time gettign that working we can do another pbr release and not need to do any change to other repos other then add pyproject.toml when you want to support centos venv installs
On Sun, Nov 12, 2023, 18:50 Arnaud arnaud.morin@gmail.com wrote:
Yes you have either to know where that file is or to copy it somewhere else.
Anyway, the thing is that you have to know where the venv is to execute it from the correct python home dir.
I am not sure this is a perfect solution but at least it unlock our ci until we figure something else.
Maybe we can switch the wsgi script to a console script instead, but as per my tests it needs a change in PBR (maybe I was not doing it right).
Le 12 novembre 2023 13:22:36 GMT+01:00, Dmitriy Rabotyagov < noonedeadpunk@gmail.com> a écrit :
Sorry for the stupid question, but how ones now should use mistral-api with uwsgi?
So given that Mistral is installed in venv, should it be configured to be smth like /opt/virtualenvs/mistral-17.0.0/lib/pythonX.YY/site-packages/mistral/api/wsgi.py ?
Why I am asking, is basically because MISTRAL_ENV_DIR is not that straightforward to define outside of the devstack, especially the part with the python version, given that venv can be created with non-default python for the system (ie, one installed with pyenv). So now configuring uwsgi becomes way more complex from regular user perspective, unless I'm missing smth.
On Sun, Nov 12, 2023, 11:11 Arnaud Morin arnaud.morin@gmail.com wrote:
Here is what I proposed for mistral CI until we managed a better or global option:
https://review.opendev.org/c/openstack/mistral/+/900566
Cheers,
On 09.11.23 - 13:31, smooney@redhat.com wrote:
On Thu, 2023-11-09 at 07:14 +0000, Arnaud Morin wrote:
I was thinking the same, but this is what I have: $ pip freeze |grep pbr pbr==6.0.0
so... that is not enough it turns out that pep 660 explcitly does not cover datafile or sciprt
it only covers pure python libs
so pbr now has support for pep-660 and editable wheels. that pep does not support our use of a pbr/setupppols/distutils custom
entrypoints
so in editbale mode nothing invokes the logic in pbr to genergate the
wsgi scripts
i was talkign to stephenfin about his this morning an i think the best
approch will be to stop using
wsgi_script in openstack in general we can support both as a
transition period.
stephen is workign on a very small poc patch to export our wsgi
scripts as console_scripts for nova
and we can see if that work with devstack as we expect.
this was aready done for gnocchi
https://github.com/gnocchixyz/gnocchi/commit/3f45e24803f4d6e88bc1f4606310585...
if you want to see what it looks like but the nova version shoudl be
closer to what we woudl expect others to do.
i dont really see a way for use to continue to support wsgi_scripts
via pbr and it actully might
make sense longterm to just move to using setuptools_scm instead as
our packaging system.
i raised my fustration at the fact that pep-660 has no way to enable
this type of extention
in
https://discuss.python.org/t/adding-support-for-wsgi-scripts-entrypoint/3090...
if the nova poc works and we agree on that direction i can try and
update the patches i submitted
do the same for other project if their maintainers done have time to
take them over but my time
is also limited.
On 08.11.23 - 23:28, Jeremy Stanley wrote: > On 2023-11-08 23:11:54 +0000 (+0000), Arnaud Morin wrote: > > Are we sure this solution works? > > I am still not having any wsgi scripts in my bin/ folder, even
with the
> > pyproject.toml file... > [...] > > For editable installs (pip install -e ...) you need the PEP 660 > support in PBR 6.0.0, which has only been out for a day now. > -- > Jeremy Stanley
Sorry, I had some time off, thus clean forgot to answer some early messages answering my concerns:
You can specify upper version bounds for things in pyproject.toml, as long as the full set of build requirements is still solvable by pip's resolver. Those can be an entirely disjoint set compared to the packages needed in the environment where the resulting wheel is installed
Yes, I was thinking about that actually, but I assume we might need some tooling to keep these in sync and updated, that gets executed during project branching for instance (we already run a bot proposing changes to adjust release notes layout). But these are details which could be figured out.
Also, if you're installing from a wheel instead of sdist or local source tree, then none of this even matters since there is no build step on the user's system; pip simply unpacks the wheel into the requested environment.
But building a wheel is also affected by that? I might be wrong here or was trying to build wheels wrong, but I think wheels build was also failing with the gnocchi case, when pyporject.toml installed the latest setuptools which removed deprecated functionality gnocchi was relying on.
Previously, you had very little control over the version of setuptools used to build or install your project. It was whatever already existed on the system as setuptools bootstrapping different versions of itself was/is not very reliable
Um, I'm not sure about that part. What we have been doing for years (and that works quite reliably until now), is to upgrade setuptools/wheels after virtualenv is initialized. So basically: $ python3 -m venv /opt/virtualenvs/mistral $ /opt/virtualenvs/mistral/bin/pip3 install --upgrade pip,setuptools,wheel --constraint constraint.txt $ /opt/virtualenvs/mistral/bin/pip3 install mistrall --constraint constraint.txt
But, such flow makes no sense with pyproject.toml (and I assume pep-517 overall) since then setuptools version inside venv is not respected with no way to override it without patching the project itself (which in case of poor maintenance can be completely broken overnight with new setuptools release).
So yeah, as pyproject.toml is the only way forward, I would suggest having and maintaining an upper cap for tools that are mentioned in it as requirements, to prevent older versions being just uninstallable within some time.
пн, 13 нояб. 2023 г. в 09:51, smooney@redhat.com:
On Sun, 2023-11-12 at 20:42 +0100, Dmitriy Rabotyagov wrote:
Well, as I said, bindir is smth you indeed know and can easily define knowing path to the venv. libdir is a different story, as you in fact don't know what is it going to be after running `python3 -m venv /opt/virtualenvs/mistral-17.0.0/` for example. As that path would depend on what python3 binary is actually representing. So afaik, the only good way then to identify libdir is to do smth like `/opt/virtualenvs/mistral-17.0.0/bin/python3 -c 'import mistral; print(mistral.__file__)'`, then get it's dirname and then append api/wsgi.py to the result. So as a regular user I would give up after not finding the binary for uwsgi and would just use eventlet server instead, to be frank, as you really need to be motivated enough to follow that path. And eventlet is not tested in devstack as assumption made that ppl should run things as wsgi app (and there's whole another thread for eventlet state and shape)...
so i woudl prefer to hold off on making any change to any project until we figure this out propelry so i woudl suggest taht mistral not make any change for right now.
we have 2 option to maintain compaitbaliy 1 we can add a wsgi script to each repo and register that as a console scipt with the same name 2 i or someone else can modify pbr's build
i need to disable build isolation in the pip install line of this https://review.opendev.org/c/openstack/pbr/+/900728/1/pbr/tests/test_integra... but i have created a test that demonstrate that the wsgi files are missing right now https://github.com/openstack/pbr/blob/master/pbr/build.py#L82-L91 just calls setuptools to build the wheel instead we can take the wheel form setup tools and before we return a can generate the wsgi script and append them to the wheel produced by setup tools.
i have not fully figured out how to do that yet but we can levage the wheel spec to achive that normally our wsgi_scripts are added to the data dir https://peps.python.org/pep-0491/#the-data-directory any file added to wheel-*.data/scripts in the wheel are added to ${prefix}/bin when the wheel is installed. This is what we are using to package the wsgi_script and install it in a non editble wheel. when we do an editbale wheel build setup tools is not invokeing pbr in a way that causes it to be generated so we just need to fix that we can even leverage python #! Rewrite to have the installer (pip) ensure that uses the venv or system python automatically. https://peps.python.org/pep-0491/#recommended-installer-features
so if peole want to spend some time gettign that working we can do another pbr release and not need to do any change to other repos other then add pyproject.toml when you want to support centos venv installs
On Sun, Nov 12, 2023, 18:50 Arnaud arnaud.morin@gmail.com wrote:
Yes you have either to know where that file is or to copy it somewhere else.
Anyway, the thing is that you have to know where the venv is to execute it from the correct python home dir.
I am not sure this is a perfect solution but at least it unlock our ci until we figure something else.
Maybe we can switch the wsgi script to a console script instead, but as per my tests it needs a change in PBR (maybe I was not doing it right).
Le 12 novembre 2023 13:22:36 GMT+01:00, Dmitriy Rabotyagov < noonedeadpunk@gmail.com> a écrit :
Sorry for the stupid question, but how ones now should use mistral-api with uwsgi?
So given that Mistral is installed in venv, should it be configured to be smth like /opt/virtualenvs/mistral-17.0.0/lib/pythonX.YY/site-packages/mistral/api/wsgi.py ?
Why I am asking, is basically because MISTRAL_ENV_DIR is not that straightforward to define outside of the devstack, especially the part with the python version, given that venv can be created with non-default python for the system (ie, one installed with pyenv). So now configuring uwsgi becomes way more complex from regular user perspective, unless I'm missing smth.
On Sun, Nov 12, 2023, 11:11 Arnaud Morin arnaud.morin@gmail.com wrote:
Here is what I proposed for mistral CI until we managed a better or global option:
https://review.opendev.org/c/openstack/mistral/+/900566
Cheers,
On 09.11.23 - 13:31, smooney@redhat.com wrote:
On Thu, 2023-11-09 at 07:14 +0000, Arnaud Morin wrote: > I was thinking the same, but this is what I have: > $ pip freeze |grep pbr > pbr==6.0.0
so... that is not enough it turns out that pep 660 explcitly does not cover datafile or sciprt
it only covers pure python libs
so pbr now has support for pep-660 and editable wheels. that pep does not support our use of a pbr/setupppols/distutils custom
entrypoints
so in editbale mode nothing invokes the logic in pbr to genergate the
wsgi scripts
i was talkign to stephenfin about his this morning an i think the best
approch will be to stop using
wsgi_script in openstack in general we can support both as a
transition period.
stephen is workign on a very small poc patch to export our wsgi
scripts as console_scripts for nova
and we can see if that work with devstack as we expect.
this was aready done for gnocchi
https://github.com/gnocchixyz/gnocchi/commit/3f45e24803f4d6e88bc1f4606310585...
if you want to see what it looks like but the nova version shoudl be
closer to what we woudl expect others to do.
i dont really see a way for use to continue to support wsgi_scripts
via pbr and it actully might
make sense longterm to just move to using setuptools_scm instead as
our packaging system.
i raised my fustration at the fact that pep-660 has no way to enable
this type of extention
in
https://discuss.python.org/t/adding-support-for-wsgi-scripts-entrypoint/3090...
if the nova poc works and we agree on that direction i can try and
update the patches i submitted
do the same for other project if their maintainers done have time to
take them over but my time
is also limited.
> > > > On 08.11.23 - 23:28, Jeremy Stanley wrote: > > On 2023-11-08 23:11:54 +0000 (+0000), Arnaud Morin wrote: > > > Are we sure this solution works? > > > I am still not having any wsgi scripts in my bin/ folder, even
with the
> > > pyproject.toml file... > > [...] > > > > For editable installs (pip install -e ...) you need the PEP 660 > > support in PBR 6.0.0, which has only been out for a day now. > > -- > > Jeremy Stanley > >
Hi Folks,
What about this issue ? Is there any agreement how this will be solved ? I've already checked reviews referred in previous emails in this chain and it seems nothing (mostly) moved forward ?
I'm also core of kolla/kolla-ansible and it seems we will also need to take some action ... I would like to know how to prepare for those changes :)
So any news ?
Thank you very much, Michal Arbet (Kevko)
Michal Arbet Openstack Engineer
Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic
+420 604 228 897 michal.arbet@ultimum.io *https://ultimum.io https://ultimum.io/*
LinkedIn https://www.linkedin.com/company/ultimum-technologies | Twitter https://twitter.com/ultimumtech | Facebook https://www.facebook.com/ultimumtechnologies/timeline
po 13. 11. 2023 v 10:23 odesílatel Dmitriy Rabotyagov < noonedeadpunk@gmail.com> napsal:
Sorry, I had some time off, thus clean forgot to answer some early messages answering my concerns:
You can specify upper version bounds for things in pyproject.toml, as
long
as the full set of build requirements is still solvable by pip's resolver. Those can be an entirely disjoint set compared to the packages needed in the environment where the resulting wheel is installed
Yes, I was thinking about that actually, but I assume we might need some tooling to keep these in sync and updated, that gets executed during project branching for instance (we already run a bot proposing changes to adjust release notes layout). But these are details which could be figured out.
Also, if you're installing from a wheel instead of sdist or local source tree, then none of this even matters since there is no build step on the user's system; pip simply unpacks the wheel into the requested environment.
But building a wheel is also affected by that? I might be wrong here or was trying to build wheels wrong, but I think wheels build was also failing with the gnocchi case, when pyporject.toml installed the latest setuptools which removed deprecated functionality gnocchi was relying on.
Previously, you had very little control over the version of setuptools
used to build or install your project. It was whatever already existed on the system as setuptools bootstrapping different versions of itself was/is not very reliable
Um, I'm not sure about that part. What we have been doing for years (and that works quite reliably until now), is to upgrade setuptools/wheels after virtualenv is initialized. So basically: $ python3 -m venv /opt/virtualenvs/mistral $ /opt/virtualenvs/mistral/bin/pip3 install --upgrade pip,setuptools,wheel --constraint constraint.txt $ /opt/virtualenvs/mistral/bin/pip3 install mistrall --constraint constraint.txt
But, such flow makes no sense with pyproject.toml (and I assume pep-517 overall) since then setuptools version inside venv is not respected with no way to override it without patching the project itself (which in case of poor maintenance can be completely broken overnight with new setuptools release).
So yeah, as pyproject.toml is the only way forward, I would suggest having and maintaining an upper cap for tools that are mentioned in it as requirements, to prevent older versions being just uninstallable within some time.
пн, 13 нояб. 2023 г. в 09:51, smooney@redhat.com:
On Sun, 2023-11-12 at 20:42 +0100, Dmitriy Rabotyagov wrote:
Well, as I said, bindir is smth you indeed know and can easily define knowing path to the venv. libdir is a different story, as you in fact
don't
know what is it going to be after running `python3 -m venv /opt/virtualenvs/mistral-17.0.0/` for example. As that path would
depend on
what python3 binary is actually representing. So afaik, the only good
way
then to identify libdir is to do smth like `/opt/virtualenvs/mistral-17.0.0/bin/python3 -c 'import mistral; print(mistral.__file__)'`, then get it's dirname and then append api/wsgi.py to the result. So as a regular user I would give up after not finding the binary for
uwsgi
and would just use eventlet server instead, to be frank, as you really
need
to be motivated enough to follow that path. And eventlet is not tested
in
devstack as assumption made that ppl should run things as wsgi app (and there's whole another thread for eventlet state and shape)...
so i woudl prefer to hold off on making any change to any project until
we figure this out propelry
so i woudl suggest taht mistral not make any change for right now.
we have 2 option to maintain compaitbaliy 1 we can add a wsgi script to each repo and register that as a console
scipt with the same name
2 i or someone else can modify pbr's build
i need to disable build isolation in the pip install line of this
https://review.opendev.org/c/openstack/pbr/+/900728/1/pbr/tests/test_integra...
but i have created a test that demonstrate that the wsgi files are
missing
right now
https://github.com/openstack/pbr/blob/master/pbr/build.py#L82-L91 just calls setuptools
to build the wheel instead we can take the wheel form setup tools and before we return a
can generate the wsgi script
and append them to the wheel produced by setup tools.
i have not fully figured out how to do that yet but we can levage the
wheel spec to achive that
normally our wsgi_scripts are added to the data dir https://peps.python.org/pep-0491/#the-data-directory any file added to wheel-*.data/scripts in the wheel are added to
${prefix}/bin when the wheel is installed.
This is what we are using to package the wsgi_script and install it in a
non editble wheel.
when we do an editbale wheel build setup tools is not invokeing pbr in a
way that causes it to be generated
so we just need to fix that we can even leverage python #! Rewrite to
have the installer (pip) ensure that uses
the venv or system python automatically.
https://peps.python.org/pep-0491/#recommended-installer-features
so if peole want to spend some time gettign that working we can do
another pbr release and not need to do any
change to other repos other then add pyproject.toml when you want to
support centos venv installs
On Sun, Nov 12, 2023, 18:50 Arnaud arnaud.morin@gmail.com wrote:
Yes you have either to know where that file is or to copy it
somewhere
else.
Anyway, the thing is that you have to know where the venv is to
execute it
from the correct python home dir.
I am not sure this is a perfect solution but at least it unlock our
ci
until we figure something else.
Maybe we can switch the wsgi script to a console script instead, but
as
per my tests it needs a change in PBR (maybe I was not doing it
right).
Le 12 novembre 2023 13:22:36 GMT+01:00, Dmitriy Rabotyagov < noonedeadpunk@gmail.com> a écrit :
Sorry for the stupid question, but how ones now should use
mistral-api
with uwsgi?
So given that Mistral is installed in venv, should it be
configured to be
smth like
/opt/virtualenvs/mistral-17.0.0/lib/pythonX.YY/site-packages/mistral/api/wsgi.py
?
Why I am asking, is basically because MISTRAL_ENV_DIR is not that straightforward to define outside of the devstack, especially the
part with
the python version, given that venv can be created with
non-default python
for the system (ie, one installed with pyenv). So now configuring uwsgi becomes way more complex from regular user perspective, unless I'm missing smth.
On Sun, Nov 12, 2023, 11:11 Arnaud Morin arnaud.morin@gmail.com
wrote:
Here is what I proposed for mistral CI until we managed a better
or
global option:
https://review.opendev.org/c/openstack/mistral/+/900566
Cheers,
On 09.11.23 - 13:31, smooney@redhat.com wrote: > On Thu, 2023-11-09 at 07:14 +0000, Arnaud Morin wrote: > > I was thinking the same, but this is what I have: > > $ pip freeze |grep pbr > > pbr==6.0.0 > > so... that is not enough > it turns out that pep 660 explcitly does not cover datafile or
sciprt
it only covers pure python libs > > so pbr now has support for pep-660 and editable wheels. > that pep does not support our use of a
pbr/setupppols/distutils custom
entrypoints > > so in editbale mode nothing invokes the logic in pbr to
genergate the
wsgi scripts > > i was talkign to stephenfin about his this morning an i think
the best
approch will be to stop using > wsgi_script in openstack in general we can support both as a transition period. > stephen is workign on a very small poc patch to export our
wsgi
scripts as console_scripts for nova > and we can see if that work with devstack as we expect. > > this was aready done for gnocchi
https://github.com/gnocchixyz/gnocchi/commit/3f45e24803f4d6e88bc1f4606310585...
> if you want to see what it looks like but the nova version
shoudl be
closer to what we woudl expect others to do. > > i dont really see a way for use to continue to support
wsgi_scripts
via pbr and it actully might > make sense longterm to just move to using setuptools_scm
instead as
our packaging system. > > i raised my fustration at the fact that pep-660 has no way to
enable
this type of extention > in
https://discuss.python.org/t/adding-support-for-wsgi-scripts-entrypoint/3090...
> > if the nova poc works and we agree on that direction i can try
and
update the patches i submitted > do the same for other project if their maintainers done have
time to
take them over but my time > is also limited. > > > > > > > > > On 08.11.23 - 23:28, Jeremy Stanley wrote: > > > On 2023-11-08 23:11:54 +0000 (+0000), Arnaud Morin wrote: > > > > Are we sure this solution works? > > > > I am still not having any wsgi scripts in my bin/
folder, even
with the > > > > pyproject.toml file... > > > [...] > > > > > > For editable installs (pip install -e ...) you need the
PEP 660
> > > support in PBR 6.0.0, which has only been out for a day
now.
> > > -- > > > Jeremy Stanley > > > > >
+ Michal Nasiadka Michal Arbet Openstack Engineer
Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic
+420 604 228 897 michal.arbet@ultimum.io *https://ultimum.io https://ultimum.io/*
LinkedIn https://www.linkedin.com/company/ultimum-technologies | Twitter https://twitter.com/ultimumtech | Facebook https://www.facebook.com/ultimumtechnologies/timeline
út 5. 3. 2024 v 15:31 odesílatel Michal Arbet michal.arbet@ultimum.io napsal:
Hi Folks,
What about this issue ? Is there any agreement how this will be solved ? I've already checked reviews referred in previous emails in this chain and it seems nothing (mostly) moved forward ?
I'm also core of kolla/kolla-ansible and it seems we will also need to take some action ... I would like to know how to prepare for those changes :)
So any news ?
Thank you very much, Michal Arbet (Kevko)
Michal Arbet Openstack Engineer
Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic
+420 604 228 897 michal.arbet@ultimum.io *https://ultimum.io https://ultimum.io/*
LinkedIn https://www.linkedin.com/company/ultimum-technologies | Twitter https://twitter.com/ultimumtech | Facebook https://www.facebook.com/ultimumtechnologies/timeline
po 13. 11. 2023 v 10:23 odesílatel Dmitriy Rabotyagov < noonedeadpunk@gmail.com> napsal:
Sorry, I had some time off, thus clean forgot to answer some early messages answering my concerns:
You can specify upper version bounds for things in pyproject.toml, as
long
as the full set of build requirements is still solvable by pip's resolver. Those can be an entirely disjoint set compared to the packages needed in the environment where the resulting wheel is installed
Yes, I was thinking about that actually, but I assume we might need some tooling to keep these in sync and updated, that gets executed during project branching for instance (we already run a bot proposing changes to adjust release notes layout). But these are details which could be figured out.
Also, if you're installing from a wheel instead of sdist or local source tree, then none of this even matters since there is no build step on the user's system; pip simply unpacks the wheel into the requested environment.
But building a wheel is also affected by that? I might be wrong here or was trying to build wheels wrong, but I think wheels build was also failing with the gnocchi case, when pyporject.toml installed the latest setuptools which removed deprecated functionality gnocchi was relying on.
Previously, you had very little control over the version of setuptools
used to build or install your project. It was whatever already existed on the system as setuptools bootstrapping different versions of itself was/is not very reliable
Um, I'm not sure about that part. What we have been doing for years (and that works quite reliably until now), is to upgrade setuptools/wheels after virtualenv is initialized. So basically: $ python3 -m venv /opt/virtualenvs/mistral $ /opt/virtualenvs/mistral/bin/pip3 install --upgrade pip,setuptools,wheel --constraint constraint.txt $ /opt/virtualenvs/mistral/bin/pip3 install mistrall --constraint constraint.txt
But, such flow makes no sense with pyproject.toml (and I assume pep-517 overall) since then setuptools version inside venv is not respected with no way to override it without patching the project itself (which in case of poor maintenance can be completely broken overnight with new setuptools release).
So yeah, as pyproject.toml is the only way forward, I would suggest having and maintaining an upper cap for tools that are mentioned in it as requirements, to prevent older versions being just uninstallable within some time.
пн, 13 нояб. 2023 г. в 09:51, smooney@redhat.com:
On Sun, 2023-11-12 at 20:42 +0100, Dmitriy Rabotyagov wrote:
Well, as I said, bindir is smth you indeed know and can easily define knowing path to the venv. libdir is a different story, as you in fact
don't
know what is it going to be after running `python3 -m venv /opt/virtualenvs/mistral-17.0.0/` for example. As that path would
depend on
what python3 binary is actually representing. So afaik, the only good
way
then to identify libdir is to do smth like `/opt/virtualenvs/mistral-17.0.0/bin/python3 -c 'import mistral; print(mistral.__file__)'`, then get it's dirname and then append api/wsgi.py to the result. So as a regular user I would give up after not finding the binary for
uwsgi
and would just use eventlet server instead, to be frank, as you
really need
to be motivated enough to follow that path. And eventlet is not
tested in
devstack as assumption made that ppl should run things as wsgi app
(and
there's whole another thread for eventlet state and shape)...
so i woudl prefer to hold off on making any change to any project until
we figure this out propelry
so i woudl suggest taht mistral not make any change for right now.
we have 2 option to maintain compaitbaliy 1 we can add a wsgi script to each repo and register that as a console
scipt with the same name
2 i or someone else can modify pbr's build
i need to disable build isolation in the pip install line of this
https://review.opendev.org/c/openstack/pbr/+/900728/1/pbr/tests/test_integra...
but i have created a test that demonstrate that the wsgi files are
missing
right now
https://github.com/openstack/pbr/blob/master/pbr/build.py#L82-L91 just calls setuptools
to build the wheel instead we can take the wheel form setup tools and before we return a
can generate the wsgi script
and append them to the wheel produced by setup tools.
i have not fully figured out how to do that yet but we can levage the
wheel spec to achive that
normally our wsgi_scripts are added to the data dir https://peps.python.org/pep-0491/#the-data-directory any file added to wheel-*.data/scripts in the wheel are added to
${prefix}/bin when the wheel is installed.
This is what we are using to package the wsgi_script and install it in
a non editble wheel.
when we do an editbale wheel build setup tools is not invokeing pbr in
a way that causes it to be generated
so we just need to fix that we can even leverage python #! Rewrite to
have the installer (pip) ensure that uses
the venv or system python automatically.
https://peps.python.org/pep-0491/#recommended-installer-features
so if peole want to spend some time gettign that working we can do
another pbr release and not need to do any
change to other repos other then add pyproject.toml when you want to
support centos venv installs
On Sun, Nov 12, 2023, 18:50 Arnaud arnaud.morin@gmail.com wrote:
Yes you have either to know where that file is or to copy it
somewhere
else.
Anyway, the thing is that you have to know where the venv is to
execute it
from the correct python home dir.
I am not sure this is a perfect solution but at least it unlock our
ci
until we figure something else.
Maybe we can switch the wsgi script to a console script instead,
but as
per my tests it needs a change in PBR (maybe I was not doing it
right).
Le 12 novembre 2023 13:22:36 GMT+01:00, Dmitriy Rabotyagov < noonedeadpunk@gmail.com> a écrit :
Sorry for the stupid question, but how ones now should use
mistral-api
with uwsgi?
So given that Mistral is installed in venv, should it be
configured to be
smth like
/opt/virtualenvs/mistral-17.0.0/lib/pythonX.YY/site-packages/mistral/api/wsgi.py
?
Why I am asking, is basically because MISTRAL_ENV_DIR is not that straightforward to define outside of the devstack, especially the
part with
the python version, given that venv can be created with
non-default python
for the system (ie, one installed with pyenv). So now configuring uwsgi becomes way more complex from regular
user
perspective, unless I'm missing smth.
On Sun, Nov 12, 2023, 11:11 Arnaud Morin arnaud.morin@gmail.com
wrote:
> Here is what I proposed for mistral CI until we managed a
better or
> global option: > > https://review.opendev.org/c/openstack/mistral/+/900566 > > Cheers, > > On 09.11.23 - 13:31, smooney@redhat.com wrote: > > On Thu, 2023-11-09 at 07:14 +0000, Arnaud Morin wrote: > > > I was thinking the same, but this is what I have: > > > $ pip freeze |grep pbr > > > pbr==6.0.0 > > > > so... that is not enough > > it turns out that pep 660 explcitly does not cover datafile
or sciprt
> it only covers pure python libs > > > > so pbr now has support for pep-660 and editable wheels. > > that pep does not support our use of a
pbr/setupppols/distutils custom
> entrypoints > > > > so in editbale mode nothing invokes the logic in pbr to
genergate the
> wsgi scripts > > > > i was talkign to stephenfin about his this morning an i think
the best
> approch will be to stop using > > wsgi_script in openstack in general we can support both as a > transition period. > > stephen is workign on a very small poc patch to export our
wsgi
> scripts as console_scripts for nova > > and we can see if that work with devstack as we expect. > > > > this was aready done for gnocchi >
https://github.com/gnocchixyz/gnocchi/commit/3f45e24803f4d6e88bc1f4606310585...
> > if you want to see what it looks like but the nova version
shoudl be
> closer to what we woudl expect others to do. > > > > i dont really see a way for use to continue to support
wsgi_scripts
> via pbr and it actully might > > make sense longterm to just move to using setuptools_scm
instead as
> our packaging system. > > > > i raised my fustration at the fact that pep-660 has no way to
enable
> this type of extention > > in >
https://discuss.python.org/t/adding-support-for-wsgi-scripts-entrypoint/3090...
> > > > if the nova poc works and we agree on that direction i can
try and
> update the patches i submitted > > do the same for other project if their maintainers done have
time to
> take them over but my time > > is also limited. > > > > > > > > > > > > > > On 08.11.23 - 23:28, Jeremy Stanley wrote: > > > > On 2023-11-08 23:11:54 +0000 (+0000), Arnaud Morin wrote: > > > > > Are we sure this solution works? > > > > > I am still not having any wsgi scripts in my bin/
folder, even
> with the > > > > > pyproject.toml file... > > > > [...] > > > > > > > > For editable installs (pip install -e ...) you need the
PEP 660
> > > > support in PBR 6.0.0, which has only been out for a day
now.
> > > > -- > > > > Jeremy Stanley > > > > > > > > >
On 2024-03-05 15:31:48 +0100 (+0100), Michal Arbet wrote:
What about this issue ? Is there any agreement how this will be solved ? I've already checked reviews referred in previous emails in this chain and it seems nothing (mostly) moved forward ?
[...]
Just as a reminder to those recently revisiting this thread (I'll admit I had forgotten myself until Jay reminded me), there is already a proposed goal: https://review.opendev.org/902807
It has very little feedback yet so I've added the [tc] tag to the subject in hopes of better bringing this thread to their attention, but if you have opinions on the proposal it would be good to record them in review comments there as well as prompting your elected TC to make a decision one way or the other. Anyone can review proposed goals, you don't have to be on the TC to offer your personal/professional input or preferences in these matters.
On Wed, 2024-03-06 at 17:05 +0000, Jeremy Stanley wrote:
On 2024-03-05 15:31:48 +0100 (+0100), Michal Arbet wrote:
What about this issue ? Is there any agreement how this will be solved ? I've already checked reviews referred in previous emails in this chain and it seems nothing (mostly) moved forward ?
[...]
Just as a reminder to those recently revisiting this thread (I'll admit I had forgotten myself until Jay reminded me), there is already a proposed goal: https://review.opendev.org/902807
justs an aside the way the goal is being implemented in nova is we are adding suppoprt for wsgi python paths while maintian the existing functionatliy
https://review.opendev.org/c/openstack/nova/+/902686 https://review.opendev.org/c/openstack/nova/+/902687
we will likely keep the PBR functionatliy till 2025.1 or 2026.1
so the main aspect of the goal is to ensure we can run all the services without needing the pbr generated scripts and the removal of that support from the services can happen at a future date.
so if we adopt this goal and implement it in the relevent project it will not have any upgrade impact initally as its additive and the only upgrade impact comes when we later decide to stop supproting the old way.
by the way this is requried for use to supprot pyproject.toml for any project that has wsgi supprot and will likely be required for using newer pip version in general since newer pip tools and other package manager for python now invent a pyproject.toml if it does not exist.
this breaks editable installs as the pbr wsgi extension does not work. while that coudl be fixed with some effort it technial debt we should try and remove so im very much in favor of adopting this goal.
i have attempted to enhance pbr to provide a bridge but i will not have time to complete that whihc is why we abandoned those patches last year.
It has very little feedback yet so I've added the [tc] tag to the subject in hopes of better bringing this thread to their attention, but if you have opinions on the proposal it would be good to record them in review comments there as well as prompting your elected TC to make a decision one way or the other. Anyone can review proposed goals, you don't have to be on the TC to offer your personal/professional input or preferences in these matters.
participants (8)
-
Arnaud
-
Arnaud Morin
-
Clark Boylan
-
Dmitriy Rabotyagov
-
Jeremy Stanley
-
Michal Arbet
-
smooney＠redhat.com
-
Stephen Finucane