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.