Skip to content
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

Breaking change in Warehouse breaks poetry lock file creation #5970

Closed
3 tasks done
cyraxjoe opened this issue Jul 8, 2022 · 10 comments · Fixed by #5972
Closed
3 tasks done

Breaking change in Warehouse breaks poetry lock file creation #5970

cyraxjoe opened this issue Jul 8, 2022 · 10 comments · Fixed by #5972
Labels
kind/bug Something isn't working as expected

Comments

@cyraxjoe
Copy link

cyraxjoe commented Jul 8, 2022

  • 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 (-vvv option).
  • Linux/Debian bookworm:
  • 1.2.0b2:
  • Sample pyproject:

Issue

The warehouse project (backend of pypi.org) applied a breaking change that affects poetry lock the releases key is no longer present in the responses, required for the pypi_repository implementation.

It can be easily verified by removing the local cache and inspecting the generated lock file, it would have an empty metadata.files property, something like:

[[package]]
name = "beautifulsoup4"
version = "4.11.1"
description = "Screen-scraping library"
category = "main"
optional = false
python-versions = ">=3.6.0"

[package.dependencies]
soupsieve = ">1.2"

[package.extras]
html5lib = ["html5lib"]
lxml = ["lxml"]

[[package]]
name = "soupsieve"
version = "2.3.2.post1"
description = "A modern CSS selector implementation for Beautiful Soup."
category = "main"
optional = false
python-versions = ">=3.6"

[metadata]
lock-version = "1.1"
python-versions = "^3.10"
content-hash = "36fc53f6339e375f6295378c7a8ecea11e3a04ba0adcbfa7aeb812e30500aad0"

[metadata.files]
beautifulsoup4 = []
soupsieve = []
@cyraxjoe cyraxjoe added kind/bug Something isn't working as expected status/triage This issue needs to be triaged labels Jul 8, 2022
@Kurt-von-Laven
Copy link

I can confirm that this issue is also affecting Poetry 1.1.13 as it is taking down all of our builds.

@novotl
Copy link

novotl commented Jul 8, 2022

👍 We're seeing the same with Poetry 1.1.8

@dimbleby
Copy link
Contributor

dimbleby commented Jul 8, 2022

I suspect a lot of people are about to learn a hard lesson about the dangers of relying on public repositories....

diff --git a/src/poetry/repositories/pypi_repository.py b/src/poetry/repositories/pypi_repository.py
index 0e5beab6..142b29d8 100644
--- a/src/poetry/repositories/pypi_repository.py
+++ b/src/poetry/repositories/pypi_repository.py
@@ -204,7 +204,7 @@ class PyPiRepository(HTTPRepository):
         )

         try:
-            version_info = json_data["releases"][version]
+            version_info = json_data["urls"]
         except KeyError:
             version_info = []

looks like it should fix things on master.

@mkniewallner
Copy link
Member

#5972 draft for now, because there may be other places where releases is used, don't know the codebase well enough.
Tested locally, and it seems to work fine.

Also backported the change for 1.1 in https://github.com/mkniewallner/poetry/commits/fix/fix-releases-key-pypi-repository-1.1

@finswimmer
Copy link
Member

Thanks a lot everyone for reporting, debugging and starting a PR 👍 Will have a look at your PR @mkniewallner

@finswimmer finswimmer reopened this Jul 8, 2022
@mkniewallner mkniewallner removed the status/triage This issue needs to be triaged label Jul 9, 2022
neersighted pushed a commit that referenced this issue Sep 17, 2022
Resolves #6076 

I've taken the JSON version of the simple API and converted it into a
`LinkSource` so that the package-finding logic in the `PyPiRepository`
is very similar to - but annoyingly not quite the same as! - the
`LegacyRepository`.

I've also taken the opportunity to refactor the `LegacyRepository` ever
so slightly to emphasise that similarity. I think I've probably fixed a
small bug re caching and pre-releases: previously the processing for
ignored pre-releases was skipped when reading from the cache.

I believe this change will tend to be a modest performance hit. Eg
consider a package like `cryptography`, for which there are maybe a
couple of dozen downloads available at each release: to get the
available versions we now have to iterate over each of those files and
parse their names, rather than simply reading the answer.

However if the API that poetry currently uses is truly deprecated I see
little choice but to suck that up - or risk being in an awkward spot
when it is turned off. cf #5970, but worse.

Most of the changes are in the test fixtures:
- unversioned fixtures were generated from the existing fixtures: I
didn't want to download fresh data and start getting different answers
than the tests were expecting
- new versioned fixtures were downloaded fresh
poetry-bot bot pushed a commit that referenced this issue Sep 17, 2022
Resolves #6076

I've taken the JSON version of the simple API and converted it into a
`LinkSource` so that the package-finding logic in the `PyPiRepository`
is very similar to - but annoyingly not quite the same as! - the
`LegacyRepository`.

I've also taken the opportunity to refactor the `LegacyRepository` ever
so slightly to emphasise that similarity. I think I've probably fixed a
small bug re caching and pre-releases: previously the processing for
ignored pre-releases was skipped when reading from the cache.

I believe this change will tend to be a modest performance hit. Eg
consider a package like `cryptography`, for which there are maybe a
couple of dozen downloads available at each release: to get the
available versions we now have to iterate over each of those files and
parse their names, rather than simply reading the answer.

However if the API that poetry currently uses is truly deprecated I see
little choice but to suck that up - or risk being in an awkward spot
when it is turned off. cf #5970, but worse.

Most of the changes are in the test fixtures:
- unversioned fixtures were generated from the existing fixtures: I
didn't want to download fresh data and start getting different answers
than the tests were expecting
- new versioned fixtures were downloaded fresh

(cherry picked from commit b61a4dd)
neersighted pushed a commit that referenced this issue Sep 17, 2022
Resolves #6076

I've taken the JSON version of the simple API and converted it into a
`LinkSource` so that the package-finding logic in the `PyPiRepository`
is very similar to - but annoyingly not quite the same as! - the
`LegacyRepository`.

I've also taken the opportunity to refactor the `LegacyRepository` ever
so slightly to emphasise that similarity. I think I've probably fixed a
small bug re caching and pre-releases: previously the processing for
ignored pre-releases was skipped when reading from the cache.

I believe this change will tend to be a modest performance hit. Eg
consider a package like `cryptography`, for which there are maybe a
couple of dozen downloads available at each release: to get the
available versions we now have to iterate over each of those files and
parse their names, rather than simply reading the answer.

However if the API that poetry currently uses is truly deprecated I see
little choice but to suck that up - or risk being in an awkward spot
when it is turned off. cf #5970, but worse.

Most of the changes are in the test fixtures:
- unversioned fixtures were generated from the existing fixtures: I
didn't want to download fresh data and start getting different answers
than the tests were expecting
- new versioned fixtures were downloaded fresh

(cherry picked from commit b61a4dd)
@Natim
Copy link

Natim commented Jan 4, 2023

It seems that Poetry 1.2.2 fixed it but 1.3.1 is back with the same issue, any idea why?
However this code is still the one provided with it.

@finswimmer
Copy link
Member

@Natim: Please open a new issue with steps to reproduce if you encounter any problems (I don't have any).

@Kurt-von-Laven
Copy link

We haven't encountered this issue on Poetry 1.3.1 either.

@Natim
Copy link

Natim commented Jan 10, 2023

Sorry, you are both right, the issue is not related, the poetry.lock file structure changed in between 1.2.2 and 1.3.1 which made disappear the metadata section, but the hashes are correctly computed in the package file section in 1.3.1.

Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Something isn't working as expected
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants