-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Poetry 2.0 doesn't support the latest PyPy release #10180
Comments
I expect this comes via importlib.metadata #!/usr/bin/env python3
import importlib.metadata as metadata
print([d.metadata.get("name") for d in metadata.distributions()]) with result
and if so I guess this either wants to go to importlib.metadata - why is it finding "standard library" packages here? Or else back to pypy - what did they do wrong to cause importlib.metadata to behave this way? |
either way this seems highly likely to cause confusion when folk try to install regular projects with regular versions of these packages, I wonder how pypy expect this to work... I'm inclined to see this as a straight pypy bug. These packages are not part of the standard library - you can tell by reading the standard library docs - and my hot take would be that pypy has no business shipping them. |
Because PyPy is written in Python, and some of these as projects that were developed because of PyPy (at least I recognize hpy and cffi as born from PyPy), I expect PyPy has to have them to function. Normally, these just hard override whatever users do - you can |
My guess is the same as @dimbleby's, the fact that |
I copied that into the PyPy issue, but I could see it being more complicated. Reporting that it is installed is correct, after all; the package is available and can be used, it's just incorrect to then think you can uninstall it or override it, which is what Poetry is doing. |
I would add that if anything has changed recently here it is more likely to be at the pypy end than at the poetry end - poetry has been detecting installed packages by asking |
The thing that changed recently is that PyPy started using unreleased versions of cffi (and hpy, only for 3.11 though). I think upstream cffi development has nearly frozen since last year, so they've either been including unreleased changes or patches. Older versions of PyPy used released packages only, AFAIK. |
does that adequately explain that anyway this is sounding more and more like a pypy problem than a poetry problem! |
PyPy has had vendored versions of
PyPy re-uses the CPython stdlib implementation of I think we all agree poetry should not be removing them. What is the best way to get that to happen? If we do not report them at all in |
If that is not what you want - well my understanding of this thread is that pypy implementation details are leaking to user programs, and if that is right then I would think pypy maintainers will want to fix that If anything, the bug here - though maybe a happy one - is that the package removal silently fails. The title of this issue seems over-dramatic. So far as I can see the only actual symptom that is reported is some confusing output. |
PyPy must present cffi, greenlet, and hpy as installed. Otherwise other package managers will try to install them. Poetry is the only one that insists on removing them. It would be nice if we could agree between us how to avoid that. I am not a packaging expert, but I can think of alternatives:
Or we could continue to ignore the problem |
What if we used the INSTALLER file spec to state "vendored", and poetry would then ignore any package with that |
Nonsense. Which others did you try? Even pip will try to uninstall your vendored packages if given requirements that contradict them:
and as henryiii points out, it is likely that the only reason that uv is not encountering this is because of a bug which they will sooner or later fix. The effect seems to be that pypy makes it impossible for users to use versions of these packages other than those that you have vendored - which would clearly be a bug: what if they want to rely on the behaviour of some older version? Or some newer version? If you want to make a proposal about how python implementations should vendor packages in a way that does not interfere with packaging tools, then I suggest that the right place to do that would be at the packaging discourse, rather than working through the individual tools one at a time. |
Thanks for the suggestion. https://discuss.python.org/t/how-to-vendor-a-package-into-a-python-distribution/80844 |
This is on a package without a lock file (yet). Poetry is basically broken out of the box on PyPy, at least if there’s a plugin being used. Poetry doesn’t actually uninstall the packages it thinks it’s uninstalling, which is why it used to work. Poetry was “uninstalling” and installing new versions of these packages, but in fact, the built in version was overriding site packages. The problem is now that the unreleased version that is being reported is confusing Poetry and causing it to fail. |
@henryiii I see this aspect of the conversation has been completely lost. At this point it probably wants breaking out into a separate issue so as not to confuse things. So far we have been discussing: in a managed environment, poetry may try to remove packages that pypy has vendored But it seems that what you are actually reporting is something quite different: that in poetry's own environment, when installing a plugin per the new mechanism, poetry locks too tightly to the packages that it sees. (And in a pypy environment this is unfortunate: poetry locks to a version of cffi that does not exist anywhere else) That bug is likely fixed simply by removing these lines, maybe if you submit a pull request their author will chip in... |
I am confused by two things, maybe they are connected.
|
1 is because of the lines I linked.
2 is because |
How can this step be told "that version already is installed, use the installed version" To solve (2), can the lock file include packages already installed in the environment? |
again repeating myself, 1 can likely be fixed simply by removing the lines that I linked. Again I invite a pull request as being a likely way to get the author of those lines to comment. A lock file is a cross-platform artifact, not related to the current environment. But since the problem (2) is more or less benign I do not know that it needs a whole lot of solving. |
I cannot in good faith submit a PR of things I don't understand. @radoering, @abn can you take a look? |
What happens if you remove these lines? I would have expected that another version of cffi is chosen and installed. Will this break the Poetry installation or does the vendored version has higher priority than the other version and this just adds more confusing output? |
no cffi is chosen because no package in the environment has a dependency on cffi Edit: maybe there are cffi dependencies, I did not actually check. But anyway then we see the other part of this bug, the vendored cffi would survive anyway. Just as it did when poetry was installed in the first place. |
I did not test, but I think removing the pinning would result in unwanted lib updates, when installing a project plugin. (Without the pins, the latest versions of all dependencies will be chosen and if they are not yet installed in Poetry's env they will be installed in the project in I think what we may need is what has been removed in #9851: We do not want to ignore installed packages during solving in this special case! |
another approach might be in the handling of |
I suspect @radoering is correct that we will end up with some unexpected updates if we don't pin. This sounds similar to "distro managed" packages conceptually if I am groking this right on skimming the thread. I also wonder how this impacts poetry projects outside of the plugin scenario. |
Description
PyPy installs a few packages required for operation that are normally on PyPI into its stdlib folder. These are
cffi
,greenlet
,hpy
, andreadline
. In the latest release of PyPy,cffi
(for PyPy 3.10 and 3.11) as well ashpy
(only on PyPy 3.11) are unreleased versions that are not available on PyPI. Poetry doesn't seem to notice that these are not in site-packages, and even thinks it can remove them directly from the standard library (I think it doesn't actually uninstall them). I hit it on a minimal template using Poetry's versioning plugin.Here's a MWE:
You can see what's happening if you leave off the VCS plugin:
But these packages are in PyPy's standard library! You can still see and import cffi in the environment, even though it claims it's been "removed".
Too many of poetry's dependencies don't provide PyPy3.11 pre-built wheels to test this on 3.11, but I assume hpy might also complain in that case.
Using Poetry from pipx does the same thing.
Workarounds
I believe Poetry just needs to ignore any package that are in Python's standard library. I'm not sure the best case for locking with a package that includes one of these dependencies, but since you can't install these (the stdlib version takes precedence anyway), I think they should just be ignored - that's basically what already happens on older PyPy's, except Poetry is now tripping up over not being able to find the unreleased versions on PyPy.
Poetry Installation Method
pip
Operating System
ubuntu 24.04
Poetry Version
Poetry (version 2.0.1)
Poetry Configuration
Python Sysconfig
sysconfig.log
Example pyproject.toml
Poetry Runtime Logs
poetry-runtime.log
The text was updated successfully, but these errors were encountered: