Inconsistent Output When Locking PyYAML #6513
Comments
Kurt-von-Laven
added
kind/bug
|
the new wheels were uploaded to pypi in that time period, as you can verify at https://pypi.org/project/PyYAML/#files. I expect the difference in behaviour is cache related, presumably you locally have a cache that does not know about the recently uploaded files. I'm not seeing a bug here. |
|
We pin the exact version of PyYAML, and we are running |
New artefacts for an existing release can be added after a version is uploaded in PyPI. This is exactly what happened here, and this can be seen here, where I guess 3.11 support has been added, and wheels got uploaded for an existing release:
|
|
That all makes sense and is very helpful; thank you. If I understand correctly, I should run |
If the newly added wheels look good to you, yes, clearing the cache locally should make sure they are discovered.
The hashes are calculated from the files that are uploaded, so depending on the algorithm, a new artefact with the same name would have a different hash (assuming that there is no possible collision for the hash function that is used). |
|
Excellent; thank you. I meant more that the |
neersighted
added
kind/question
See python-poetry/poetry#6513 for an explanation of the partial-update (additions) to pyyaml-related content hashes
|
Given stale cache causes inconsistent locking, isn't this a bug? We've just been chasing why our lockfile flipflops between 2 machines, and this seems to be it. Workaround we're using for now is to run with |
- disable poetry cache while performing locks, as cache invalidation doesn't seem to work still. ref: python-poetry/poetry#5282 ref: python-poetry/poetry#6513
- disable poetry cache while performing locks, as cache invalidation doesn't seem to work still. ref: python-poetry/poetry#5282 ref: python-poetry/poetry#6513
- disable poetry cache while performing locks, as cache invalidation doesn't seem to work still. ref: python-poetry/poetry#5282 ref: python-poetry/poetry#6513
- disable poetry cache while performing locks, as cache invalidation doesn't seem to work still. ref: python-poetry/poetry#5282 ref: python-poetry/poetry#6513
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
I am on the latest Poetry version.
I have searched the issues of this repo and believe that this is not a duplicate.
If an exception occurs when executing a command, I executed it again in debug mode (
-vvvoption).OS version and name: Ubuntu 22.04 LTS
Poetry version: 1.2.0
Link to the contents of your pyproject.toml file:
pyproject.tomlIssue
Some time between yesterday (September 13th, 2022) at 13:39 UTC and today (September 14th, 2022) at 08:28 UTC,
poetry lock --no-updatebegan producing inconsistent output on the samepyproject.toml, breaking all of our CI pipelines. When run locally on Ubuntu 22.04 LTS,poetry lock --no-updatecontinues to consistently produce this poetry.lock. This is consistent with past runs on Ubuntu 22.04 LTS in CI and hence what I perceive to be the correct output. Here is a CI workflow showing the diff (reproduced below) between the old (correct) and new (incorrect) output. The new output appears consistent across CI runs. Note also that two spaces were added beforemetadata.python-versions, which is the focus of #6201, not this issue.The text was updated successfully, but these errors were encountered: