You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Fall back to public PyPI if 'ConnectionError' occurs #2783
I have searched the issues of this repo and believe that this is not a duplicate.
I have searched the documentation and believe that my question is not covered.
Feature Request
I have a private PyPI repository defined in pyproject.toml. The repository is located within my corporate network. When I don't use VPN and try to install any package, I get such an error:
ConnectionError
HTTPConnectionPool(host=SOME_HOST, port=80): Max retries exceeded with url: SOME_URL (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x109f17f10>: Failed to establish a new connection: [Errno 8] nodename nor servname provided, or not known'))
which is quite obvious. But what I would like to see is an option to ignore the error and try to install packages from the next expected repository, in that case - the public PyPI. Currently, the fallback mechanism works only for cases when a repository is reachable, but some package is missing.
PS The same error occurs even if secondary = true is used - which of course is reasonable, but it's not always the behaviour you would like to achieve.
Reacted by Danny Vilela, Alexander Varchenko, Siegfried Gessulat, Vlad, Ismaïl Lachheb and Ben Butterworth
Honestly I wouldn't want to see this ever getting implemented in Poetry. It goes against the whole determinism / reproducibility idea of the lockfile that is one of the keypoints of the project. If the lockfile says that a package must be downloaded from repo xyz then that same package must always be downloaded from repo xyz.
Note how there can be several reasons why you want to make sure packages are always downloaded from the same source, other than mere determinism:
The package on the private repo might not be exactly the same as the one on pypi (eg a wheel compiled in a different way)
Overall I think your best chance to see this getting implemented is to develop a plugin on your own. I'm invoking an extra opinion from core maintainers before closing this issue - @dimbleby
@ralbertazzi
That's why I mentioned that functionality as an option, not as default behaviour. The request was created before plugins were introduced, if it's achievable this way - that should be also fine.
Just one more point - you focused on poetry.lock in your comment, but what should be the behaviour on poetry add / poetry update level, yet before modifying the lockfile? If I have multiple primary sources defined and one of them is unreachable, should I be able to add package from one of the other sources or should it also fail? I haven't checked what's the current behaviour in Poetry 1.5 yet, but I still wonder what is actually expected.
Activity
stormsw commentedon Mar 25, 2021
Any progress on merging the PR?
abn commentedon Mar 28, 2021
@stormsw does #3337 resolve this?
stormsw commentedon Mar 28, 2021
@abn I think this one is bit different.
The lines are here https://github.com/python-poetry/poetry/blob/master/poetry/repositories/legacy_repository.py#L435
ralbertazzi commentedon Jun 8, 2023
Honestly I wouldn't want to see this ever getting implemented in Poetry. It goes against the whole determinism / reproducibility idea of the lockfile that is one of the keypoints of the project. If the lockfile says that a package must be downloaded from repo xyz then that same package must always be downloaded from repo xyz.
Note how there can be several reasons why you want to make sure packages are always downloaded from the same source, other than mere determinism:
Overall I think your best chance to see this getting implemented is to develop a plugin on your own. I'm invoking an extra opinion from core maintainers before closing this issue - @dimbleby
jaklan commentedon Jun 8, 2023
@ralbertazzi
That's why I mentioned that functionality as an option, not as default behaviour. The request was created before plugins were introduced, if it's achievable this way - that should be also fine.
Just one more point - you focused on
poetry.lockin your comment, but what should be the behaviour onpoetry add/poetry updatelevel, yet before modifying the lockfile? If I have multipleprimarysources defined and one of them is unreachable, should I be able to add package from one of the other sources or should it also fail? I haven't checked what's the current behaviour in Poetry 1.5 yet, but I still wonder what is actually expected.