Private registries not taken into consideration in local dependencies

• 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).

• OS version and name: Ubuntu 18.04

• Poetry version: 1.0.5

Issue

When you reference a local path as a dependency, and that reference has a registry setup, it’s not taken into account during poetry install:

in repo/bigproject/pyproject.toml:

[tool.poetry.dependencies]
local-dep = { path = "../local-dep" }

in repo/local-dep/pyproject.toml:

[tool.poetry.dependencies]
private-lib = "*"

[tool.poetry.sources]
...  # private repo setup here

• I can lock from repo/local-dep just fine (it checks the private repo 👍)
• I cannot lock from repo/bigproject; it will not attempt to use the private registry

Workaround: Add the repo information in repo/bigproject/pyproject.toml even though it doesn’t technically needs it.

Sidenote: Overall the local dependencies feature seems to have opened a can of worms. For instance:

• multiple references will create oddities in some lock files such as this-lib = 'somepath/../someotherpath/../this-lib/ where it should just be this-lib/.
• you can’t build a sdist, because the source gets copied in a temporary folder without the local references. the paths are then evaluated from the temp folder and not from the original pyproject.toml file location and it will eventually fail saying the local package cannot be found.
• private repositories need to be copied everywhere (what the current issue is about)

[jonapich]

possibly related issues: #2078 #2178

(now I wish I had 2278 😆 )

[snejus]

@jonapich I had exactly the same issue and I found that my virtual environment used pip= ^9.0.0(even though v20 is available) and thought that this could have been related to the issue. I upgraded it with poetry run pip install pip==19.3.1 and the issue was gone. I use poetry 1.1.0a1 if that helps by the way.

It looks like when a virtual environment gets created, it installs pip version that was bundled together with the required python release (python 3.6.9 in my case (I see you’re using py3.6 too), which was bundled with pip 9). Currently, it seems that there isn’t a way to override this behaviour through poetry, so we’ll have to keep upgrading pip manually before this is fixed (WIP here: #1971). See #732 , #1661 , #1962 and #1651 for similar issues.