Open mtkennerly opened 1 day ago
Mixing pipx installation with poetry self
is a bad idea, if you have used pipx to install poetry then you will also want to use pipx to inject plugins into that installation.
There are existing issues saying similar.
That's fair, but I can reproduce it without using Pipx. I think the crux of the issue is that the internal poetry.lock
is reused across different Python versions:
$ py -3.13 -m pip install poetry==1.8.4
$ py -3.13 -m poetry self add "poetry-dynamic-versioning[plugin]"
- Downgrading msgpack (1.1.0 -> 1.0.7): Failed
ChefBuildError
Same thing. Iirc poetry self
commands only really make sense for installs from the installer script.
similar examples include #7170 and your own #6456
iirc poetry self commands only really make sense for installs from the installer script.
possibly not even that. I never use the installer so I am not totally sure, but perhaps it too will behave the same way.
poetry self
is broken in more than one way - eg #7872 - and I recommend just not using it ever.
Hmm, #7170 definitely sounds like the same issue. #6456 is a bit different - that should occur regardless of how Poetry is installed.
Just to be clear, do you think that essentially the only reason the internal poetry.lock
got into a weird state to begin with is because of using poetry self
inappropriately?
I dont know that it even did get into a "weird" state, it probably is a perfectly good lock file but it just happens that the solution that it gives includes a version of msgpack that does not have wheels for python3.13, and which your system is not set up to build.
That solution is likely influenced in some way by the unlocked environment from the original install, but I doubt that it will be useful or interesting to figure out exactly what combination of circumstances lead to that outcome.
For me anyway, it is a lot simpler to advise: avoid poetry self
also the pyproject.toml
in your attachment is making the mistake of installing poetry
into a project environment. See the big red box.
Or is that from the poetry installation? Did you perhaps previously do a poetry self
command successfully then do a pipx install
over the top of that, and then poetry self
again?
After the pipx install
you could then have an environment that was ahead of the lock file and so it should be expected that next time you give control to poetry it would try to downgrade.
The solution is going to be to use one or the other mechanism consistently (and imo preferably "not poetry self
")
Or is that from the poetry installation?
Yes, the pypoetry.zip attachment contains my %APPDATA%/pypoetry
folder.
Did you perhaps previously do a
poetry self
command successfully then do apipx install
over the top of that, and thenpoetry self
again?
I've certainly used a mix of poetry self
and pipx
commands through the course of testing my plugin, so I want to say yes, and I do understand now that that's problematic. However, consider the following reproduction that only uses the installer script:
rm -rf ~/AppData/Roaming/pypoetry
curl -sSL https://install.python-poetry.org | POETRY_VERSION=1.7.1 py -3.10 -
~/AppData/Roaming/Python/Scripts/poetry.exe self lock
curl -sSL https://install.python-poetry.org | POETRY_VERSION=1.8.4 py -3.13 -
~/AppData/Roaming/Python/Scripts/poetry.exe self add "poetry-dynamic-versioning[plugin]"
Results in:
- Downgrading poetry-plugin-export (1.8.0 -> 1.6.0)
The downgrade "makes sense" in terms of the lock file, but it's probably not something the user would want in this situation.
If you first run ~/AppData/Roaming/Python/Scripts/poetry.exe self lock
before installing poetry-dynamic-versioning
, then Poetry updates the lock file to include poetry-plugin-export 1.8.0, and therefore no downgrade occurs.
The installer script's --uninstall
option does remove ~/AppData/Roaming/pypoetry
, but if you're just upgrading directly, then it stays in place. If you're only really supposed to use poetry self
in conjunction with the installer script, then perhaps the installer script should automatically run poetry self lock
to help avoid this kind of downgrade?
IMO we should be running less poetry self
rather than more - but feel free to try a pull request and see how those with power to merge feel about it.
Description
I maintain a Poetry plugin, and I got a report (https://github.com/mtkennerly/poetry-dynamic-versioning/discussions/198) about issues installing it with Python 3.13. It seems that changing Python versions may result in strange behavior with Poetry's internal
poetry.lock
file. Specifically, when I would try to install the plugin, Poetry would downgrade some dependencies that weren't related to the plugin, and some of those downgrades would fail to install.I had to delete
%APPDATA%/pypoetry/poetry.lock
in order to make the plugin installation work. I also found that, instead of deleting it, I could runpoetry-py3.13 self lock
, which would update the lock file, and then the plugin installation would work.To reproduce:
poetry.lock
from pypoetry.zippy -3.13 -m pipx install --suffix='-py3.13' poetry
)poetry-py3.13 self add "poetry-dynamic-versioning[plugin]"
Would it be possible for Poetry to detect that the Python version has changed and recommend resetting/updating the internal
poetry.lock
?Workarounds
%APPDATA%/pypoetry/poetry.lock
.poetry-py3.13 self lock
first before trying to install the plugin.Poetry Installation Method
pipx
Operating System
Windows 11
Poetry Version
Poetry (version 1.8.4)
Poetry Configuration
Python Sysconfig
Example pyproject.toml
No response
Poetry Runtime Logs