Skip to content

python completions are wrong for the non-default interpreter #3840

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

Closed
2 tasks done
asomers opened this issue Feb 11, 2017 · 2 comments
Closed
2 tasks done

python completions are wrong for the non-default interpreter #3840

asomers opened this issue Feb 11, 2017 · 2 comments
Labels
bug Something that's not working as intended
Milestone

Comments

@asomers
Copy link
Contributor

asomers commented Feb 11, 2017

  • Have you checked if problem occurs with fish 2.5.0?
  • Tried fish without third-party customizations (check sh -c 'env HOME=$(mktemp -d) fish')?

fish version installed (fish --version):
fish, version 2.5.0-180-g0a929f7a-dirty

OS/terminal used:
FreeBSD 12.0, QTerminal

Commit f70b1ff simplified the Python completion code, but it introduced a new bug. On a system with a symlink from python to either python2 or python3, python.fish will use the completions for the default interpreter, regardless of which interpreter is invoked. The problem is that, unlike in the old code, the new python2.fish and python3.fish files don't pass the executable name to python.fish.

Reproduction steps

  1. Ensure that /usr/local/bin/python points to /usr/local/bin/python2
  2. Type "python3 -" and press tab
  3. Among the suggestions should be "-q", "-X", "-b", and "-bb". But none of those will be there. Instead you'll see "-3", "-t", and "-Q"
@krader1961 krader1961 added the bug Something that's not working as intended label Feb 11, 2017
@krader1961 krader1961 added this to the fish-future milestone Feb 11, 2017
@krader1961
Copy link
Contributor

There are two problems here. First is that the version specific completions (e.g., share/completions/python2.fish) rely on the dynamic, run-time, version check in share/completions/python.fish. The second is that the generic share/completions/python.fish should defer the version specific completions to run-time since using mechanisms like pyenv or Anaconda conda command can change which version the python command refers to. Obviously fixing the second problem obviates fixing the first.

While it would be straightforward to fix the first problem it would be better to fix the second problem since doing so fixes both in a generic manner. Unfortunately I don't see any way to solve the second problem in a straightforward manner. None of the other completions, such as for ruby, appear to deal with multiple versions that might be invoked by the same name depending on how the shell environment has been manipulated.

So it looks like the only realistic option at this time is to add the version specific completions found in share/completions/python.fish to the version specific completion scripts.

uqs pushed a commit to freebsd/freebsd-ports that referenced this issue Feb 11, 2017
Eliminate errors during command completion for python, python2, and python3 if
the /usr/local/bin/python symlink does not exist.  Additionally, even if the
symlink does exist, the completions will be wrong for the non-default
interpreter.  So I'm simply deleting the problematic completions altogether.  I
opened an upstream bug for the latter issue.

fish-shell/fish-shell#3840

While I'm here, delete an extraneous patch file for DOCS=off

PR:		216987
Reported by:	Keren Sky <keren_sky@live.com>
Approved by:	brd (ports, implicit)


git-svn-id: svn+ssh://svn.freebsd.org/ports/head@433836 35697150-7ecd-e111-bb59-0022644237b5
uqs pushed a commit to freebsd/freebsd-ports that referenced this issue Feb 11, 2017
Eliminate errors during command completion for python, python2, and python3 if
the /usr/local/bin/python symlink does not exist.  Additionally, even if the
symlink does exist, the completions will be wrong for the non-default
interpreter.  So I'm simply deleting the problematic completions altogether.  I
opened an upstream bug for the latter issue.

fish-shell/fish-shell#3840

While I'm here, delete an extraneous patch file for DOCS=off

PR:		216987
Reported by:	Keren Sky <keren_sky@live.com>
Approved by:	brd (ports, implicit)
@faho faho closed this as completed in f9664f2 Feb 11, 2017
faho added a commit that referenced this issue Feb 11, 2017
Some things like pyenv can change what `python` refers to, so what we
detect when we load the completions can become invalid later.

Also mentioned in #3840.
@faho faho modified the milestones: 2.6.0, fish-future Feb 11, 2017
@faho
Copy link
Member

faho commented Feb 11, 2017

Should be fixed now.

So it looks like the only realistic option at this time is to add the version specific completions found in share/completions/python.fish to the version specific completion scripts.

That's what I ended up doing.

None of the other completions, such as for ruby, appear to deal with multiple versions that might be invoked by the same name depending on how the shell environment has been manipulated.

One difference here is that python's version brouhaha is special. I don't think the ruby community is as split on versions as python's is. For more information, I refer to lwn.net's comment section on an article that mentions python somewhere.

develop7 pushed a commit to develop7/fish-shell that referenced this issue Apr 17, 2017
The issue here was that the `python` completion did a version check on
the `python` binary, so it would complete python2 stuff if system
python was py2, even if the user tried to complete `python3`.

This isn't beautiful, but it's more resilient than e.g. doing magic
with `commandline`.

Fixes fish-shell#3840.
develop7 pushed a commit to develop7/fish-shell that referenced this issue Apr 17, 2017
Some things like pyenv can change what `python` refers to, so what we
detect when we load the completions can become invalid later.

Also mentioned in fish-shell#3840.
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 18, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something that's not working as intended
Projects
None yet
Development

No branches or pull requests

3 participants