Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pip upgrade warning is bypassed when pip is a dependency #6841

Closed
ncoghlan opened this issue Aug 7, 2019 · 5 comments · Fixed by #6864

Comments

@ncoghlan
Copy link
Member

@ncoghlan ncoghlan commented Aug 7, 2019

Helping to debug a contributor setup issue at the PyCon AU sprints, we eventually tracked the problem down to:

  • briefcase needed a more recent pip
  • "pip install --upgrade briefcase" implicitly tried to upgrade pip, but had the usual Windows issues with trying to replace a running executable
  • the warning about this case didn't get displayed
@triage-new-issues triage-new-issues bot added the triage label Aug 7, 2019
@pfmoore

This comment has been minimized.

Copy link
Member

@pfmoore pfmoore commented Aug 7, 2019

Yeah, the heuristics for working out when we're trying to use pip to upgrade itself aren't 100% reliable. I don't think anyone would object to improved detection of this case, but we don't know how to do it. Suggestions (and working code 🙂) welcome, of course!

@pradyunsg

This comment has been minimized.

Copy link
Member

@pradyunsg pradyunsg commented Aug 7, 2019

Hmm... We're checking if "pip" is in the requirement set, which should be robust to this.

I guess there's something about this assumption when I wrote that, that's not correct. 🙃

@pfmoore

This comment has been minimized.

Copy link
Member

@pfmoore pfmoore commented Aug 7, 2019

I think it's that pip is not in the explicit requirement set, but is pulled in as a dependency when installing one of the requested requirements. I don't think we can do much about that, as we only find out once the install process has started (although I may well be wrong, I'm going from a pretty vague memory of how it works...)

@pradyunsg

This comment has been minimized.

Copy link
Member

@pradyunsg pradyunsg commented Aug 7, 2019

Right. We're both speculating from memory. XD

I've fallen for this before so... let's wait till someone finds the time to investigate what's actually happening.

@atugushev

This comment has been minimized.

Copy link
Contributor

@atugushev atugushev commented Aug 8, 2019

I've tried to reproduce the issue on AppVeyor and found that adding "pip" to the list below fixes easily the issue:

pip_names = [
"pip.exe",
"pip{}.exe".format(sys.version_info[0]),
"pip{}.{}.exe".format(*sys.version_info[:2])
]

Checkout my test case and AppVeyor log:
https://github.com/atugushev/test-package/blob/master/.appveyor.yml
https://ci.appveyor.com/project/atugushev/test-package/builds/26548167

Tried on atugushev@8462580

@triage-new-issues triage-new-issues bot removed the triage label Aug 11, 2019
@lock lock bot added the S: auto-locked label Sep 24, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Sep 24, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
5 participants
You can’t perform that action at this time.