-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Comments
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 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 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. |
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
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)
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.
Should be fixed now.
That's what I ended up doing.
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. |
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.
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.
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 eitherpython2
orpython3
,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
The text was updated successfully, but these errors were encountered: