When you use --isolated, does this also ignore PIP_INDEX_URL env variable ??

@HansAarneLiblik, the pip docs call this case out explicitly https://pip.pypa.io/en/stable/cli/pip/#cmdoption-isolated

Just a note that this also (obviously) makes pip ignore the PIP_CACHE_DIR :-/

PIP_CACHE_DIR does nothing with Poetry as we use our own system for caching.

But the pip caches the built wheel file to its cache. Which by this --isolated flag is reverted to default location

It shouldn't be, see #3439.

This is the output we get during one of the craches - note that PIP_CACHE_DIR is present and is pointing elsewhere
(the crash itself we suspect to be caused by how pip, not poetry, handles access to cache from multiple instances of pip running simultaneously

  Building wheels for collected packages: future

    Building wheel for future (pyproject.toml): started

    Building wheel for future (pyproject.toml): finished with status 'done'

    Created wheel for future: filename=future-0.18.2-py3-none-any.whl size=491086 sha256=a7afdfefd81979c60312ec0fbada3b92361d7159c2b783f3c791cedf5de0bfac

    Stored in directory: c:\windows\system32\config\systemprofile\appdata\local\pip\cache\wheels\e6\98\20\6f689e25af7abda5431cc4480b86e91d9242e2a6211188f2d9

The cache location is default (in this case for system user)

Odd, I think pip behavior may have changed. However, you won't be able to set PIP_CACHE_DIR per Poetry worker anyway, so the better move here is to set poetry config installer.parallel false to turn off concurrency. Also make sure that the pip in use by Poetry (the one in the target environment) is up-to-date.

Hello, thanks for the tip, will have a look at that!

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.