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

Completions should not perform version check (completions hang & spam terminal) #5135

Closed
mqudsi opened this issue Mar 31, 2018 · 4 comments
Closed
Labels
auto-locked Outdated issues that have been locked by automation state: needs reproducer Need to reproduce issue type: enhancement Improvements to functionality

Comments

@mqudsi
Copy link

mqudsi commented Mar 31, 2018

  • Pip version: 9.0.3
  • Python version: 3.5.2
  • Operating system: Linux/WSL

pip's default completions (at least for fish) perform the version check during background completions tasks. i.e. the user merely types pip and the shell hangs until the version check is completed (since fish does not run subshells asynchronously).

While bash does run subshells asynchronously and is therefore not affected by the aforementioned delay, completions under both fish and bash are affected by the next part of this bug:

When an out-of-date pip is found, again while running in the background and without any actual command execution on behalf of the user who has only typed in pip<SPACE> in the terminal until this point, /dev/tty is spammed with "pip out of date, run pip install --upgrade pip" messages.

For these reasons, --disable-pip-version-check must be included in all pip commands that are run during the completion process.

@mqudsi mqudsi changed the title Completions should not perform version check Completions should not perform version check (completions hang & spam terminal) Mar 31, 2018
@pradyunsg
Copy link
Member

Thanks for filing this @mqudsi! :)

This has come up before (#4768 (comment)) and I guess a dedicated issue for this is a good idea. I don't think there's any major caveats to doing this.

I'll mark this as "awaiting PR" since I'm basically willing to merge a PR that implements this properly. I might even get to this myself, if I get the time.

@pradyunsg pradyunsg added type: enhancement Improvements to functionality state: awaiting PR Feature discussed, PR is needed labels Apr 7, 2018
@cjerdonek
Copy link
Member

cjerdonek commented Aug 10, 2019

I looked at the code for this (even for 9.0.3 as this issue reports), and I can't seem to see how the code is behaving as described. If you look at the autocomplete() function which is called at the very beginning of pip's execution before pip "runs," you can see that if the PIP_AUTO_COMPLETE environment variable is set, pip will call sys.exit(1) without proceeding further. Here is that code (and for 9.0.3):

pip/pip/__init__.py

Lines 70 to 80 in ece1c6b

def autocomplete():
"""Command and option completion for the main option parser (and options)
and its subcommands (and options).
Enable by sourcing one of the completion shell scripts (bash, zsh or fish).
"""
# Don't complete if user hasn't sourced bash_completion file.
if 'PIP_AUTO_COMPLETE' not in os.environ:
return
cwords = os.environ['COMP_WORDS'].split()[1:]
cword = int(os.environ['COMP_CWORD'])

So unless I'm missing something, the only thing that occurs to me that could explain the reported behavior is if the PIP_AUTO_COMPLETE environment wasn't being passed along when the completion script was being invoked.

The version-check is run when command.main() is invoked, and the autocomplete() function is called before then.

@pradyunsg
Copy link
Member

Yep yep @cjerdonek!

Could someone provide a reproduction for this issue, clearly demonstrating how the completion was installed?

@cjerdonek cjerdonek added S: awaiting response Waiting for a response/more information state: needs reproducer Need to reproduce issue and removed state: awaiting PR Feature discussed, PR is needed labels Aug 11, 2019
@chrahunt
Copy link
Member

chrahunt commented Sep 6, 2019

Since it's been some time without a response, I will close this issue. If anyone can provide the information above to demonstrate that this is a problem, then please let us know!

@chrahunt chrahunt closed this as completed Sep 6, 2019
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Oct 6, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 6, 2019
@pradyunsg pradyunsg removed the S: awaiting response Waiting for a response/more information label Mar 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation state: needs reproducer Need to reproduce issue type: enhancement Improvements to functionality
Projects
None yet
Development

No branches or pull requests

4 participants