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 }}
This repository has been archived by the owner on Jun 18, 2019. It is now read-only.
I've had chef runs fail when our local devpi was down, even though mypackage==1.2.3 was already installed(!). So it seems to me that the pip_outdated/PIP_HACK_SCRIPT call somehow always wants to talk to the package index, regardless of what the local installation state is (and whether an explicit target version is specified, which makes the whole "check for outdated" gesture superfluous anyway). This seems rather wrong to me, however I'm not versed enough in pip internals to even make a suggestion where this behaviour comes from or what could be done to improve it. Any ideas? Thanks for your help!
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I've stumbled across some suprising behaviour. Given a declaration like this
I've had chef runs fail when our local devpi was down, even though
mypackage==1.2.3
was already installed(!). So it seems to me that the pip_outdated/PIP_HACK_SCRIPT call somehow always wants to talk to the package index, regardless of what the local installation state is (and whether an explicit target version is specified, which makes the whole "check for outdated" gesture superfluous anyway). This seems rather wrong to me, however I'm not versed enough in pip internals to even make a suggestion where this behaviour comes from or what could be done to improve it. Any ideas? Thanks for your help!The text was updated successfully, but these errors were encountered: