Version 1.2 breaks pypa/build on Python 3.8 and 3.9 #206
Comments
|
It would appear #199 returns a stdlib ( |
|
/cc @jaraco @takluyver @abravalheri for awareness. |
|
Responding to #199 (comment):
I have two concerns with that:
|
|
My inclination is to say that this is either a bug in setuptools (which should spot when it gets a stdlib object and deal with it) or in the None of which helps that much, unless those projects can release fixes ASAP, but at the same time, I sympathise with @takluyver's point that if we can't rely on being able to safely pass distribution objects around, we're going to be at risk of yet more areas of incompatibility popping up. |
We might then need to yank 1.1.0 as well, since that was already reported as a regression (#192) and 1.2.0 was meant to fix it. And then I presume people would be upset about the problem that #165 was written to fix again. I totally agree that I don't want to do this. A slightly less drastic version might be to change the conditional added in #199 - If setuptools is committed to using the backport on 3.8 & 3.9, we could decide that compatibility with setuptools is more important than anything else and insist on using the backport for those versions as well. But that presumably breaks other code that does the right thing and uses the stdlib version. And it's an extra headache for anyone who cares about bootstrapping, since |
|
Has this issue actually been observed anywhere outside of a contrived test case? Build re-exposes setuptools without the prepare hook to test reading a project’s metadata from a wheel. Unless this incompatibility is causing builds to fail in the wild, yanking’s probably an overreaction at this point.
Sent with [Proton Mail](https://proton.me/mail/home) secure email.
…On Sunday, 6 October 2024 at 14:31, Thomas Kluyver ***@***.***> wrote:
> If we do this, we should yank 1.2.0 and release a 1.3.0 with the right python-requires...
We might then need to yank 1.1.0 as well, since that was already reported as a regression ([#192](#192)) and 1.2.0 was meant to fix it. And then I presume people would be upset about the problem that [#165](#165) was written to fix again. I totally agree that I don't want to do this.
A slightly less drastic version might be to change the conditional added in [#199](#199) - if sys.version_info >= (3, 8): - to (3, 10). This would mean no importlib[._]metadata integration on Python 3.8 or 3.9 (like v1.1), but keep the integration (like v1.2) for newer Pythons.
If setuptools is committed to using the backport on 3.8 & 3.9, we could decide that compatibility with setuptools is more important than anything else and insist on using the backport for those versions as well. But that presumably breaks other code that does the right thing and uses the stdlib version. And it's an extra headache for anyone who cares about bootstrapping, since importlib_metadata needs setuptools & setuptools_scm to build it. I really don't like that option.
—
Reply to this email directly, [view it on GitHub](#206 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AHNRFWFPYWAJWNRDMA2U44DZ2ENRFAVCNFSM6AAAAABPN6QQT2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJVGQYDGMRUGY).
You are receiving this because you commented.Message ID: ***@***.***>
|
|
It broke check-sdist’s tests too, where it was just building an SDist for setuptools. I believe it breaks any package that has a local backend at “.” and uses setuptools. Including setuptools itself (https://github.com/pypa/setuptools/blob/66a8aee91de7ed8b0f819fb836e5543212e4b860/pyproject.toml#L4) and setuptools-scm. I’ve verified locally that you can’t build setuptools-scm anymore. Setuptools-scm uses uv to build SDists & wheels now, which is why their CI hasn't broken this last week. You can find others at https://github.com/search?type=code&q=path%3Apyproject.toml+backend-path - look for the ones with setuptools and “.”. |
|
Oh. It fixed setuptools local backend at "." based on our actual usage of build to bootstrap setuptools at least on newer Python. Wait, is this only about sdist? Because we don't build any sdists through wheel in our deptree since the only point of building sdist is redistributing sources. We only build wheels. |
|
This is only about Python 3.8 and 3.9, everything works fine after that. It breaks both: $ git clone https://github.com/cvxpy/cvxpy
$ cd cvxpy
$ pipx run --python 3.9 build --sdist
...
TypeError: expected string or bytes-like object
$ pipx run --python 3.9 build --wheel
...
TypeError: expected string or bytes-like object
$ pipx run --python 3.10 build --sdist
...
Successfully built cvxpy-1.6.0.tar.gzIf you avoid the new pyproject-hooks, it works: $ uvx --python 3.9 --from build --with pyproject-hooks==1.1.0 pyproject-build --sdist
...
Successfully built cvxpy-1.6.0.tar.gzYou have to remove the |
As a reminder,
That said, an |
|
Oh, do we understand why this issue only affects Python 3.9 and earlier? If the underlying problem is a distribution with no |
|
Isn't this the same problem we were discussing in #195 (comment)? We are in the "complicated zone" when (Frustratingly, I tested the patch against the setuptools test suite and it passed at that point in time https://github.com/abravalheri/setuptools/pull/14/files) |
@jaraco, I suspect that this parish aspect is an issue in setuptools because it uses entry-points to generate the |
|
Hi @henryiii, in pypa/setuptools#4680 I am trying to change the code path so that the conflict between You probably can test the PR specific version of setuptools by installing https://github.com/abravalheri/setuptools/archive/refs/heads/issue-pyproject-hooks-206-take2.zip |
|
I could confirm this affecting Debian 11 (i.e. Python 3.9) and Ubuntu 20.04 (i.e. Python 3.8). My OBS packages are most likely fine with setuptools v59.6.0 (for Python <= 3.7) and v75.2.0 (for Python >= 3.8), but only Debian 11 and Ubuntu 20.04 coming with compile error, see https://build.opensuse.org/project/monitor/home:alvistack?defaults=0&failed=1&arch_x86_64=1&repo_Debian_11=1&repo_xUbuntu_20_04=1: This happened since pyproject-hooks 1.2 get released; I am now going to pin pyproject-hooks 0.13.1 for those legacy OS, and let's see if it could help the condition :-( |
|
Have you tried updating setuptools? This should have been fixed there. |
Already having setuptools v75.2.0 with Debian 11 and Ubuntu 20.04, but still failing :-( |
In that case, maybe the issue could be addressed in Setuptools by keeping the egg-info directory off sys.path until it's populated. |
@jaraco just some quick update that may help: with alvistack/adrienverge-yamllint@3de73c2 I had try to In case of Ubuntu 22.04 (see https://build.opensuse.org/package/live_build_log/home:alvistack/adrienverge-yamllint-1.35.1/xUbuntu_22.04/x86_64): In case of Debian 11 (see https://build.opensuse.org/package/live_build_log/home:alvistack/adrienverge-yamllint-1.35.1/Debian_11/x86_64): |
@jaraco I have already implemented something in @hswong3i could you maybe try to reduce the reproducer to its most basic form using only setuptools APIs (maybe also |
1.2 has broken build's test suite when using
backend-pathon Python 3.8 and 3.9 (and check-sdist's setuptools test, though I just dropped the setuptools test there). See pypa/build#820, python/importlib_metadata#508, henryiii/check-sdist#55. I've finally narrowed it down to this package's 1.2 release.Backend path is
".", and setuptools is makingtest_no_prepare.egg-info, which is then getting picked up as a nameless distribution, which causes a confusing error when trying to get the name and falling back on None, then not handling the None case.Originally posted by @henryiii in #199 (comment)
The text was updated successfully, but these errors were encountered: