Make install.py work on Arch Linux

[Valloric]

It currently doesn't (see comment) because it uses !#/usr/bin/env python as the shebang, which on Arch uses python3. The old install.sh script worked around it like this:

PYTHON_BINARY=python
if command_exists python2; then
  PYTHON_BINARY=python2
fi

It might be possible to use this logic inside the install.py script (so that build.py is correctly invoked with a Python 2 process) while making the install.py script itself run on both python2 and python3.

@micbou Thoughts?

[micbou]

What we could do is remove the following check in the build.py script:

major, minor = sys.version_info[ 0 : 2 ]
if major != 2 or minor < 6:
  sys.exit( 'The build script requires Python version >= 2.6 and < 3.0; '
            'your version of Python is ' + sys.version )

and make the install.py, build.py, and run_tests.py scripts python3-compatible which, from my tests, is already the case.

[FooSoft]

Maybe use !#/usr/bin/env python2?

[micbou]

The issue is that not all distributions ship with a python2 executable or symlink.

[vheon]

@micbou

What we could do is remove the following check in the build.py script:

major, minor = sys.version_info[ 0 : 2 ]
if major != 2 or minor < 6:
  sys.exit( 'The build script requires Python version >= 2.6 and < 3.0; '
            'your version of Python is ' + sys.version )

and make the install.py, build.py, and run_tests.py scripts python3-compatible which, from my tests, is already the case.

Are there any drawback using this approach?

Isn't possible to have a system like:

• Installed both python3-32bit and python2-64bit
• /usr/bin/env python uses python3 but vim is compiled against python2 (so YCM can work)

??

Would that cause some problem?

[micbou]

I don't think so because, regardless of the python version used to run those scripts, cmake will pick the right one (python2) to build ycmd. Even the tests will run fine because we call the nosetests executable from the run_tests.py scripts.

[vheon]

Then we should be careful in the windows branch because if I'm not mistaken here we would compile a different architecture from the one needed.

[micbou]

In this case, the build will fail because cmake will not find the python2-32bit library. If python2-32bit is also installed then it will work with Vim 32bit and fail with Vim 64bit.

We could add an option to specify the architecture with the default being the current behavior.

[Valloric]

If just removing the python2 check in build.py works, then we could go with that. It would be great if we could somehow ensure that the required files will indeed remain python3 compatible.

[micbou]

We can do this by using a tool like futurize. Each time we update the scripts, we run futurize on them to maintain python2/3 compatibility.

[Valloric]

@micbou That sounds nice; I'm concerned about us forgetting to do that though. People sending random PRs for build.py would certainly not know they'd have to run the tool, and relying on us to point it out in PR review is error-prone.

[vheon]

We could think to make that a test in travis: If in a PR the build.py file is the same as the build.py file after calling futurize on it then we're good otherwise we would know because travis is failing.

[Valloric]

@vheon That sounds like a solid idea! I have a slight concern that it assumes that futurize is infallible, but it's much better than not having a test.

[rafaelnp]

I installed the python2 package and ran:

python2 ./install.py  --clang-completer

It did work here. It may not be the perfect solution, but did the job.

[Valloric]

@rafaelnp Yeah that's obviously going to work, but the point is to make that not necessary. :)

[abspoel]

I found a fix for this here: http://stackoverflow.com/a/26056481/2606953

See PR #1702

[artemjackson]

I fell into this trap too on ArchLinux
please add some Wiki about python2 and workaround described by @rafaelnp

[vheon]

@artemjackson we are in the process of porting YCM/ycmd to be python3 compatible, then I believe that this issue will be closed.

[micbou]

Fixed by PR #2016.