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
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?
Inasmuch as this is possible, I suppose that's an easier way around the problem there.
2. 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.