Comment 0 for bug 1741634

virtualenv-tools has been unmaintained for a while, or at least unmodified with pending PR.
In the past we raised a few issues against it [2], and had to do conditional behavior depending on distros [1].
virtualenv-tools is a python2 only tool, and will break with python3 (it would be easy to move it to python3, because the code is simple, but I foresee issues with the print statements already!).

Anyway, on top of that we are victim of a bug while changing paths.

Our repo build process builds a virtualenv and pip install software on it.
By default, the path of python in the virtualenv for any bin in the tgz is something like #!/tmp/openstack-venv-builder/venvs/keystone/bin/python.

This lines comes virtualenv itself, as proven by the first line of the venv build's log (for example /var/log/repo/venv_build_keystone-master-x86_64.log):
"New python executable in /tmp/openstack-venv-builder/venvs/keystone/bin/python"
This line comes is logged during our venv-build-script.sh process, ${VENV_CREATE_COMMAND} is the first command to log on the ${ROLE_VENV_LOG}, and generates a few lines.
This venv-build-script.sh script takes the virtualenv options, for example /var/www/repo/os-releases/master/ubuntu-16.04-x86_64/venv-build-options-os_keystone.txt, which contains the virtualenv command, in my example: "/usr/local/bin/virtualenv --always-copy --extra-search-dir /var/www/repo/os-releases/master/ubuntu-16.04-x86_64 --never-download").
Long story short, the "New executable" line come from [3], which formats the py_executable, whose value is (unless python interpreter path is set with -p), sys.executable [4].

I haven't dugged deeper on that part, but I expect that some sys.executable can give different versions on different systems,
some could return python2 instead of python.
So on those systems, the generated line would be #!/tmp/openstack-venv-builder/venvs/keystone/bin/python2 as shown in the log [5].

virtualenv-tools wouldn't recognize those shabangs [6] because they don't end with python, and therefore won't modify them.

The impact is now that the pip installed packages in the venv are pointing to a wrong executable: the path #!/tmp/openstack-venv-builder/venvs/keystone/bin/python2 won't exist on the destination machine.

We should probably get rid of virtualenv-tools, or be more explicit with the executable used, all the way in the process, and replace it with simply line in files (sedding) the py files. The binary files should not be shipped in the virtualenv tgz anyway.

[1]: https://github.com/openstack/openstack-ansible-os_keystone/blob/a48a73089286a370312a35fc7df54a6a3a513fa2/tasks/keystone_install.yml#L165-L171
[2]: https://github.com/fireteam/virtualenv-tools/issues/5
[3]: https://github.com/evrardjp/virtualenv/blob/master/virtualenv.py#L1217
[4]: https://github.com/evrardjp/virtualenv/blob/master/virtualenv.py#L1205
[5]: http://logs.openstack.org/24/504224/40/check/openstack-ansible-deploy-all_metal-ubuntu-xenial/9b0dec0/logs/host/repo/venv_build_keystone-master-x86_64.log.txt.gz
[6]: https://github.com/fireteam/virtualenv-tools/blob/master/virtualenv_tools.py#L68-L69