Resolution of dependencies substantially slower when using private repositories #4113
Description
-
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: Fedora 34
-
Poetry version: 1.1.6
-
Link of a Gist with the contents of your pyproject.toml file: https://gist.github.com/MasterNayru/602f564ca19c68906fdb3c5a1eba2818
Issue
I am getting a huge difference in speed when resolving dependencies on the same project when only using PyPi vs using a private repository. The private repository (AWS CodeArtifact, in this case) is configured to look use PyPi as an upstream source for content when it isn't found locally, which makes this difference in speed even more difficult for me to understand as the package contents should be identical for all packages in my project (I am not actually using any private packages in my project yet).
When I have only PyPi enabled (by commenting out the tool.poetry.source block in my linked gist, after having run a poetry update already so that the cache is fully populated, I get this time:
$ poetry update -vvv
<snip>
1: selecting importlib-metadata (4.3.0)
1: derived: zipp (>=0.5)
PyPI: 21 packages found for zipp >=0.5
1: selecting zipp (3.4.1)
PyPI: 32 packages found for importlib-resources >=1.0
1: fact: importlib-resources (5.1.4) depends on zipp (>=3.1.0)
1: selecting importlib-resources (5.1.4)
PyPI: 42 packages found for colorama *
1: selecting colorama (0.4.4)
PyPI: 7 packages found for atomicwrites >=1.0
1: selecting atomicwrites (1.4.0)
1: Version solving took 0.471 seconds.
1: Tried 1 solutions.
and when I enable that block, I get this time:
$ poetry update -vvv
<snip>
1: selecting importlib-metadata (4.3.0)
1: derived: zipp (>=0.5)
codeartifact: 21 packages found for zipp >=0.5
1: selecting zipp (3.4.1)
codeartifact: 32 packages found for importlib-resources >=1.0
1: fact: importlib-resources (5.1.4) depends on zipp (>=3.1.0)
1: selecting importlib-resources (5.1.4)
codeartifact: 42 packages found for colorama *
1: selecting colorama (0.4.4)
codeartifact: 7 packages found for atomicwrites >=1.0
1: selecting atomicwrites (1.4.0)
1: Version solving took 48.303 seconds.
1: Tried 1 solutions.
Is there any reason why enabling this repo would cause a 100x increase in resolution time when it has all of the wheels downloaded locally already? Is there something in the responses poetry gets from PyPi when it looks up packages that could explain the huge increase in time? If poetry actually looks in the wheels for information about the packages, given that the wheels will literally be from the same place, I am just really finding it hard to understand what is going on here.