Poetry: Poetry install always reinstalls all packages when used in legacy repo

[Nitori-]

• [x] I am on the latest Poetry version.
• [x] 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).

• OS version and name: Ubuntu 20.04

• Poetry version: 1.0.6, 1.0.8
• Link of a Gist with the contents of your pyproject.toml file: https://gist.github.com/Nitori-/45e49ac8feb993c11158decd4ba1fc67

Issue

Whenever I run poetry install it seems any existing packages are "upgraded" to the exact same version:

$ poetry install
Installing dependencies from lock file


Package operations: 0 installs, 51 updates, 0 removals

  - Updating certifi (2020.4.5.1 -> 2020.4.5.1)
  - Updating chardet (3.0.4 -> 3.0.4)
  - Updating idna (2.9 -> 2.9)
  - Updating markupsafe (1.1.1 -> 1.1.1)
  - Updating pyparsing (2.4.7 -> 2.4.7)
  - Updating pytz (2020.1 -> 2020.1)
  - Updating six (1.15.0 -> 1.15.0)
  - Updating urllib3 (1.25.9 -> 1.25.9)
  - Updating alabaster (0.7.12 -> 0.7.12)
  - Updating atomicwrites (1.4.0 -> 1.4.0)
  - Updating attrs (19.3.0 -> 19.3.0)
  - Updating babel (2.8.0 -> 2.8.0)
  - Updating docutils (0.16 -> 0.16)
  - Updating imagesize (1.2.0 -> 1.2.0)
  - Updating jinja2 (2.11.2 -> 2.11.2)
  - Updating lazy-object-proxy (1.4.3 -> 1.4.3)
  - Updating more-itertools (8.3.0 -> 8.3.0)
  - Updating packaging (20.4 -> 20.4)
  - Updating pluggy (0.13.1 -> 0.13.1)
  - Updating py (1.8.1 -> 1.8.1)
  - Updating pygments (2.6.1 -> 2.6.1)
  - Updating requests (2.23.0 -> 2.23.0)
  - Updating snowballstemmer (2.0.0 -> 2.0.0)
  - Updating sphinxcontrib-applehelp (1.0.2 -> 1.0.2)
  - Updating sphinxcontrib-devhelp (1.0.2 -> 1.0.2)
  - Updating sphinxcontrib-htmlhelp (1.0.3 -> 1.0.3)
  - Updating sphinxcontrib-jsmath (1.0.1 -> 1.0.1)
  - Updating sphinxcontrib-qthelp (1.0.3 -> 1.0.3)
  - Updating sphinxcontrib-serializinghtml (1.1.4 -> 1.1.4)
  - Updating wcwidth (0.2.3 -> 0.2.3)
  - Updating wrapt (1.12.1 -> 1.12.1)
  - Updating appdirs (1.4.4 -> 1.4.4)
  - Updating astroid (2.4.1 -> 2.4.1)
  - Updating click (7.1.2 -> 7.1.2)
  - Updating coverage (4.5.4 -> 4.5.4)
  - Updating isort (4.3.21 -> 4.3.21)
  - Updating mccabe (0.6.1 -> 0.6.1)
  - Updating pycodestyle (2.6.0 -> 2.6.0)
  - Updating pydocstyle (5.0.2 -> 5.0.2)
  - Updating pyflakes (2.2.0 -> 2.2.0)
  - Updating pytest (4.6.11 -> 4.6.11)
  - Updating sphinx (2.4.4 -> 2.4.4)
  - Updating toml (0.10.1 -> 0.10.1)
  - Updating black (18.9b0 -> 18.9b0)
  - Updating pathlib2 (2.3.5 -> 2.3.5)
  - Updating pylama (7.7.1 -> 7.7.1)
  - Updating pylint (2.5.2 -> 2.5.2)
  - Updating pytest-cov (2.9.0 -> 2.9.0)
  - Updating pytest-ct-ext (2.0.5 -> 2.0.5)
  - Updating scandir (1.10.0 -> 1.10.0)
  - Updating sphinx-rtd-theme (0.4.3 -> 0.4.3)
  - Installing porg (1.49.0)

[PetterS]

I was not able to reproduce this with 1.0.7 for our internal repos.

[dbanty]

This happens for me with Poetry 1.0.7 against our internal Gemfury repo. I've seen this before in older versions, seems like a regression of some sort.

[gtmanfred]

We are also experiencing this with artifactory. Pinning to 1.0.5 for now.

[frankier]

Happens for me on 1.0.7, and additionally all packages are reinstalled every time a package is added. What is a legacy repo?

[frankier]

Related: https://github.com/python-poetry/poetry/issues/1612

[sdispater]

For people encountering this issue: did you try relocking your dependencies?

There was a bug with custom repositories where the source_type of a package was not set in the lock file. Now that it's fixed (see https://github.com/python-poetry/poetry/pull/2484), if you did not update your lock file Poetry will think that both packages do not have the same origin and, as such, will update them (relevant part of the code https://github.com/python-poetry/poetry/blob/master/poetry/puzzle/solver.py#L95).

[mxab]

I deleted the poetry.lock file and run poetry lock again.
Still getting all the:

  - Updating six (1.15.0 -> 1.15.0)
  - Updating docutils (0.15.2 -> 0.15.2)
...

messages

[sdispater]

I was able to reproduce the issue.

It's a bug caused by the fix in #2484. A fix is coming.

[Nitori-]

Verified fixed in 1.0.9. Thanks for the quick fix!