Open mapa17 opened 2 weeks ago
it means exactly what it says: pyproject.toml changed significantly since poetry.lock was last generated, and you should run poetry lock [--no-update] to fix the lock file.
since you have not provided any way to reproduce whatever it is you are seeing, it is hard to say more.
Thank you for the reply. Maybe i was unclear in my description of the problem.
Using poetry 1.8.3 (in the docker image and the local dev env) building of the image will fail because poetry.lock is detected to be not in sync. Running an poetry lock --no-update
has no affect, because the lock file is up-to-date.
I can switch in the docker build to poetry 1.7.1 which still detects the file as outdated, but continues to install (seemingly, updating the lock file in place?).
My bug report is about 1.8.3 detecting the lock file as not in sync.
again: you have provided no way to reproduce this so it is impossible to say whether you are right, whether poetry is right, or where either of you is going wrong
this report is currently unactionable
Description
Hi, I am using poetry inside a Dockerfile to prepare an venv that contains a private azuredevops repository.
Building the docker image locally, works by pinning poetry to 1.7.1 (see https://github.com/python-poetry/poetry/issues/9042). Running the same docker file within another azure pipeline as a DOCKERv2 Task, I can see poetry install taking a very long time, throwing the warning
pyproject.toml changed significantly since poetry.lock was last generated. Run
poetry lock [--no-update]to fix the lock file.
Does this mean, the lock file is recreated? Specially for types-pytz it takes a very long time.
Workarounds
Hopefully
Poetry Installation Method
pip
Operating System
Azure Pipeline Ubuntu-Latest
Poetry Version
1.7.1
Poetry Configuration
Python Sysconfig
No response
Example pyproject.toml
No response
Poetry Runtime Logs