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

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

Closed
asomers opened this Issue Feb 11, 2017 · 2 comments

Comments

Projects
None yet
3 participants
@asomers
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 label Feb 11, 2017

@krader1961 krader1961 added this to the fish-future milestone Feb 11, 2017

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Feb 11, 2017

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.

Contributor

krader1961 commented Feb 11, 2017

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

asomers
shells/fish: fix completions for python
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

shells/fish: fix completions for python
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 in f9664f2 Feb 11, 2017

faho added a commit that referenced this issue Feb 11, 2017

Check python version at runtime for completions
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

This comment has been minimized.

Show comment
Hide comment
@faho

faho Feb 11, 2017

Member

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.

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.

mat813 pushed a commit to mat813/freebsd-ports that referenced this issue Feb 13, 2017

asomers
shells/fish: fix completions for python
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: https://svn.freebsd.org/ports/head@433836 35697150-7ecd-e111-bb59-0022644237b5

develop7 added a commit to develop7/fish-shell that referenced this issue Apr 17, 2017

Don't wrap pythonX completions
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 #3840.

develop7 added a commit to develop7/fish-shell that referenced this issue Apr 17, 2017

Check python version at runtime for completions
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment