[RFE] Allow to filter tox environment for system python

[tyll]

The selinux python module is not available on pypi, only a shim to load the system python module is. To run something in tox on Travis it would be nice to let this only run if the python version matches the system python version. Currently the user needs to keep track of the python version and update the tox travis config accordingly afaiu.

[ryanhiebert]

That's an interesting use case. I think the first thing I'd need to see is how we'd determine that the current Python matches the system Python (does it actually need to be the system Python, or just the have the version match?). Once we see how to implement such a check, then I'd want to figure out how tox-travis could be of assistance in making use of that. I'm not opposed to such a feature, but that this stage I'm not sure what it would look like.

[tyll]

My initial idea for detection is to check if /usr/bin/python3 is the current python (or the same version). I do not think it matters to actually verify that it is the same python binary if this makes things easier just the same version. Would be strange for travis to provide an extra python binary with the same version as the system python IMHO.

The specific use case it to be able to use selinux in tox on Travis, the challenge is that the selinux module is a binary module that is not available in pypi (there is only a shim that tries to load the system python module: https://github.com/ssbarnea/selinux/pull/3). So therefore the module cannot be compiled by pip for the running python version.

Here is my tox config that I created for this:
https://github.com/linux-system-roles/network/pull/107/files

GitHub

Configure Molecule in Travis CI by vcrhonek · Pull Request #107 · linux-system-roles/network

Configures Molecule to do basic checks (lint/syntax, run, idempotence, Ansible check mode functionality) of the role with default parameters (tests/tests_default.yml) using Travis CI and centos6/7 ...

[rpkilby]

The specific use case it to be able to use selinux in tox on Travis

Out of curiosity, is there anything that is Travis-specific? Or is it more:

The specific use case it to be able to use selinux in tox in a non-selinux environment

[jayvdb]

This sounds like a problem similar to many other modules which are distro/system libraries not usually packaged on pypi, and often have a shim for them. And most of these system libraries are loosing their py2 version as py2 EOL approaches, and only have py3 versions.

If I understand correctly, the selinux shim setup.py does fail if it is run on the wrong version, and something is needed to help prevent that.

One I have worked with recently, and is not quite perfect yet for my own distro, but works on others, is rpm. https://github.com/junaruga/rpm-py-installer

This isnt too different to the problem at #126 , where there are system problems with a dependency on a linux distro version (xenial vs trusty) rather than linux distro python version (2 vs 3).

Some solutions there may be helpful.

Another approach which is more applicable for this issue, but could also work for Django, is for tox-travis to be able to inspect apt: packages: when building the env list. Or a more raw, and extremely versatile, approach is for tox-travis to allow env list selection based on the presence of a filename on the host.

GitHub

junaruga/rpm-py-installer

An installer to enable the RPM Python binding in any environment. - junaruga/rpm-py-installer

[tyll]

The specific use case it to be able to use selinux in tox on Travis

Out of curiosity, is there anything that is Travis-specific? Or is it more:

On my normal Fedora system (which provides a variety of Python 3 versions but only one version with system modules) the tox.ini works with basepython = python3 because this is the platform python version. Also I have other tests that run on specific python versions because I do not need selinux for my project but only to run the molecule tests. On Travis I need to specify which tox environment to run for which version:

[travis]
python =
  2.6: py26
  2.7: py27,coveralls,flake8,pylint
  3.5: molecule_lint,molecule_syntax,molecule_test
  3.6: py36,black,ensure_non_running_provider
  3.7: py37
  3.8: py38

The Python 3.5 requirement comes from Travis because the newest image is using Python 3.5 as the system python version. So it should be something like system_python3 or maybe just 3.

[tyll]

If I understand correctly, the selinux shim setup.py does fail if it is run on the wrong version, and something is needed to help prevent that.

The special case is that I only need to run the tox environment once per travis build (or job?) and not for every python version. Also I do not care about the specific python version except that it should be the system python 3 version.

[ryanhiebert]

Interesting enough, I do not neccesarily expect that any Python version will be the Travis version. I'd rather expect that all of the Python versions you might choose from would be install using pyenv or something similar under the hood, likely even creating a new virtualenv to go with it.

If you do identify the system Python somehow, and you can use it, and if you want that Python to run that specific job, I suspect that the cleanest approach will be to add a job to the job: section of the .travis.yml (formerly matrix), and add in the TOXENV=whatever to the environment for that job. That is a great way, supported directly by tox even without tox-travis, to specify exactly which tox envs will run for that job. That strikes me as most likely the best tool for this job.

[jayvdb]

Providing a specific way to get the system python for a testenv sounds very useful. I recall that being commonly done in Travis precise days, when precise was still a reasonable platform that users/servers might be using. That become less sensible as Travis images become outdated and very unlikely to be what real users would be using. I havent seen system python on Travis done in combination with tox -- usually a rather raw approach is used. If there was a tox plugin solution for this, I suspect automatically setting 'sitepackages=true' for that testenv would be desirable to make it automatically have all of the packages installed via apt: packages:

iirc, it is possible to ask pyenv to switch to the system python.

It might be that the solution to this problem is https://pypi.org/project/tox-pyenv/ (or an enhancement to it), and then maybe some extra glue in tox-travis to work with nicely tox-pyenv

PyPI

tox-pyenv

tox plugin that makes tox use `pyenv which` to find python executables

[jayvdb]

@tyll, I have a solution which should work for you , and something I think that tox-travis and/or tox-pyenv can be enhanced to simplify, or potentially a new tox plugin tox-pyenv-system to glue it all together.

My currently challenge is getting tox-travis running smoothly when even when the Travis language is not 'python'. e.g. matrix at https://travis-ci.org/jayvdb/coala-bears/builds/536638517 . The problem is the Travis languages have various dist: and different python3 on the base image, and I also need to create some fake languages. I dont want to be installing a consistent python3 on all images, due to the time it takes. I need to re-use the system python3 if it is good enough. Also a few of the languages need a python2; e.g. nodegpy is python 2 only, and almost any non-trivial node project depends on nodegpy.

https://github.com/doloopwhile/pyenv-register can add system pythons.

https://github.com/doloopwhile/pyenv-register/issues/2 means it doesnt work with Python 3.6+ , but that should be easy to fix, and cloning https://github.com/garyp/pyenv-register works as a temporary fix at least.

After registering the system pythons, the following activates them.

pyenv global $(pyenv versions --bare | fgrep 'system-3' --max-count 1)
             $(pyenv versions --bare | fgrep 'system-2' --max-count 1)

Then install tox-pyenv and you should have roughly what you are looking for to make tox's py27 and py3x aliases work smoothly wrapping the system pythons.

From what you've written, I guess you also want to have both py36_spawned and py36_system (not necessarily these names) as separate factors in the same tox invocation, and possibly also need to have an alias py3_system which would match py35_system or py36_system depending on the system python version.

I am still working on my setup, so this is a bit ugly, but copied here so you can avoid some of the problems I've bypassed so far.

script:
  # ...
  # Must use `source` due to exports in the script
  - source the_script_below_which_forces_27_and_36.sh
  # ...

Where the_script_below_which_forces_27_and_36.sh is

set -e -x
if [ -z "$(which pyenv)" ]; then
  git clone https://github.com/pyenv/pyenv.git ~/.pyenv;
  export PYENV_ROOT="$HOME/.pyenv";
  export PATH="$PYENV_ROOT/bin:$PATH";
fi
# https://github.com/doloopwhile/pyenv-register/pull/3
git clone https://github.com/garyp/pyenv-register.git \
  $(pyenv root)/plugins/pyenv-register

SYSTEM_PYTHONS=$(ls /usr/bin/python[23] \
                    /usr/bin/python[23].[0-9] \
                    /usr/bin/python[23].[0-9].[0-9] 2>/dev/null || true)
for pybin in $SYSTEM_PYTHONS $(which python2.7) $(which python3.6); do
  pyenv register -f $pybin || true
done
if [ -z "$(pyenv versions | fgrep '3.6' --max-count 1)" ]; then
  git clone https://github.com/s1341/pyenv-alias.git \
    $(pyenv root)/plugins/pyenv-alias;

  VERSION_ALIAS=3.6 pyenv install 3.6.3;
fi
set +x

Travis CI - Test and Deploy Your Code with Confidence

GitHub

doloopwhile/pyenv-register

Pyenv plugin to use system installed Python. Contribute to doloopwhile/pyenv-register development by creating an account on GitHub.

GitHub

garyp/pyenv-register

Pyenv plugin to use system installed Python. Contribute to garyp/pyenv-register development by creating an account on GitHub.