Python 3.6 and 3.7 with system_site_packages enabled fails to activate on xenial

Languages Python
1

I got

The command "source ~/virtualenv/python3.6_with_system_site_packages/bin/activate" failed and exited with 1 during .

error when I want to test my project against different versions of Python (3.6 and 3.7) on xenial distro with system_site_packages: true enabled like:

virtualenv:
    system_site_packages: true

this is the job log: https://travis-ci.org/DragonComputer/Dragonfire/jobs/476074315

The problem is; I need the system site packages since my application depends on a lot of libraries installed with apt-get. I saw this answer of Donald Stufft but it did not satisfy me.

Is it possible to test my project against all these Python versions with system_site_packages enabled? This is my .travis.yml file:

dist: xenial
sudo: required
language: python
virtualenv:
    system_site_packages: true
python:
    - "3.5"
    - "3.6"
    - "3.7"
services:
    - mysql
addons:
    apt:
        packages:
            - xvfb
cache:
    directories:
        - /usr/share/dragonfire
before_install:
    - mysql -u root -e "CREATE DATABASE dragonfire;"
install:
    - sudo ./install-dev.sh --no-model
    - sudo pip3 install pytest-faulthandler
    - export DISPLAY=':99.0'
    - Xvfb :99 -screen 0 1024x768x24 > /dev/null 2>&1 &
before_script:
    # stop the build if there are Python syntax errors or undefined names
    - flake8 . --count --select=E901,E999,F822,F823 --show-source --statistics
    # exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide
    - flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics
script:
    - python3 -m pytest --capture=sys
notifications:
    on_success: change
    on_failure: change  # `always` will be the setting once code changes slow down
2

You don’t. “System site-packages” is only a thing for Python versions provided by distro – which for Xenial are 2.7.12 and 3.5.1. Other Python versions are installed manually (into /opt as of this writing), and the only global packages there are pip and setuptools (you can see all this by examining the Python tarball that the build log refers to).

So if you’re using alternative Python versions, you don’t have access to any apt-get Python packages anyway.

As such, the most straightforward solution would be to install all Python packages you need with pip (or otherwise) into the virtualenv – regardless of whether apt also provides them for distro-supplied versions – and be done with it.

The fact that using system_site_packages: true limits you to distro-provided Python versions is documented, so it’s not a bug, either:

Building a Python Project - Travis CI :

If you decide to use apt anyway, note that for compatibility reasons, you’ll only be able to use the default Python versions that are available in Ubuntu (e.g. for Trusty, this means 2.7.6 and 3.4.3).