compiled python should not set sys.executable to vim

[dyno]

https://github.com/vim/vim/archive/v8.1.0600.tar.gz
compiled on Mac with --enable-python3interp (brew installed python 3.7.1)
:py3 print(sys.executable) points to executable of the vim binary
which cause issue like davidhalter/jedi-vim#889

and according to python documents
it should point to the python interpreter.

sys.executable
A string giving the absolute path of the executable binary for the Python interpreter, on systems where this makes sense. If Python is unable to retrieve the real path to its executable, sys.executable will be an empty string or None.

[tonymec]

FWIW, I am unable to reproduce this on openSUSE Linux 15.0.

In my own-compiled Huge Vim 8.1.618 compiled with +python -python3, I see

:py print(sys.executable)
/usr/bin/python

which points to the Python 2.7.14 from the openSUSE distro.

In openSUSE's Huge Vim 8.0.1568 compiled with +python/dyn +python3/dyn, I see

:py3 print(sys.executable)
/usr/bin/python3

which points to the Python 3.6.5 executable.

Best regards,
Tony.

[dynofu]

as the problem pointed out, the problem only happened on Mac as far as I know.

[tonymec]

as the problem pointed out, the problem only happened on Mac as far as I know.

The original post said the problem happened on the Mac. It said nothing about whether or not it also happened on other platforms. So I tried, and reported what I found.

Best regards,
Tony.

[dyno]

sorry for the confusion, i should provide more context in the description.
the problem seems to be only exhibited on Mac. i tried to do a binary search on the release.
but cannot find a good start as there is compiling error for earlier releases.

• v7.4.001 - cannot compile
• v7.4.100 - same behavior as v8.1.0001 sys.executable is set to the vim command.

#!/usr/bin/env bash

export PATH=/usr/local/opt/ccache/libexec:$PATH

#make distclean
rm -f auto/config.cache
./configure --enable-python3interp
time remake

./vim -e +"redir>>/dev/stdout | py3 print(sys.executable + '\n')" -scq!

[bstaletic]

I'm not a Windows user, but I believe sys.executable evaluates to vim executable there as well. YouCompleteMe had to implement a custom logic to avoid sys.executable.

[k-takata]

I confirmed that sys.executable points to the vim binary on Windows.

[nuko8]

Oops, I didn't notice that the issue was originally reported in conjunction with macOS until people started talking about Windows.

The oldest macOS version I can access to is El Capitan (10.11.6) and the machine has Python 2.7.10 and Python 3.4.9.

Interestingly, with that Mac, :py3 print(sys.executable) gives a wrong value similar to what @dyno reported, while :py print(sys.executable) gives the correct value.

i tried to do a binary search on the release. but cannot find a good start as there is compiling error for earlier releases.

That's because macOS gave a change to a Carbon-related system header file when Mavericks (10.9) was released. So Vim older than 7.4.062 won't compile on macOS >= 10.9 unless --disable-darwin is passed to configure, IIRC.

It seems that the bug is specific to python3interp and has long been overlooked, as @dyno reported that 7.4.100 showed the same behavior. YMMV, though.

[bstaletic]

Here's a snippet from YCM's paths.py:

  WIN_PYTHON_PATH = os.path.join( sys.exec_prefix, 'python.exe' )
  # On UNIX platforms, we use sys.executable as the Python interpreter path.
  # We cannot use sys.executable on Windows because for unknown reasons, it
  # returns the Vim executable. Instead, we use sys.exec_prefix to deduce the
  # interpreter path.
  python_interpreter = WIN_PYTHON_PATH if utils.OnWindows() else sys.executable

[nuko8]

Hmm, macOS is a certified UNIX since 10.5 (Leopard), while Linux is not...

[tonymec]

Hmm, macOS is a certified UNIX since 10.5 (Leopard), while Linux is not...

Indeed, the makers and users of what is commonly known as «a Linux distribution» i.e. the Linux kernel, the GNU («GNU Not Unix») command-line utilities, the X11 GUI, the Gnome, KDE, and other GUI programs, etc., don't much care about «Unix certification» and the red tape that goes with it; they are content with using their software «as if» it were Unix without the need to formally get a Unix license (and even by taking pains not to use any proprietary Unix code).

This said, what Linux distributions certainly aren't is an MS-Windows system: the only «windows» we have are X windows, whose inner workings are considerably different from those of MS-Windows.

I bet utils.OnWindows() would return FALSE on Mac OSX so IIUC the YCM workaround wouldn't work unchanged there.

[bstaletic]

I bet utils.OnWindows() would return FALSE on Mac OSX so IIUC the YCM workaround wouldn't work unchanged there.

utils.OnWindows() just returns sys.platform == 'win32'. If sys.executable didn't work on macOS, I'm sure we (YCM maintainers) would notice by now. Even if we didn't have tests and macOS CI set up, on of the core developers is a macOS user.