# Language: python with system\_site\_packages failing in Xenial

**URL:** <https://travis-ci.community/t/language-python-with-system-site-packages-failing-in-xenial/5261>\
**Category:** Xenial\
**Tags:** build-env, python, travis-build\
**Created:** [September 30, 2019, 9:55am UTC](https://travis-ci.community/t/language-python-with-system-site-packages-failing-in-xenial/5261 "2019-09-30T09:55:59Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![ferdnyc](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/ferdnyc/32/2277_2.png) [@ferdnyc](https://travis-ci.community/u/ferdnyc)\
**Post date:** [September 30, 2019, 9:55am UTC](https://travis-ci.community/t/language-python-with-system-site-packages-failing-in-xenial/5261/1 "2019-09-30T09:55:59Z")

</div>

Apologies if this has already been posted, a quick search didn’t seem to turn anything up, but there were a lot of hits.

I’m trying to cut our build scripts over to a more modern Travis setup (from the current versions which brute-forces everything using sudo), and I’m having a problem switching over to using:

```auto
language: python
virtualenv:
  system_site_packages: true

```

The build matrix I’m setting up does two different Linux builds, one in Xenial and the other in Bionic. The Xenial build [is failing](https://travis-ci.org/ferdnyc/openshot-qt/jobs/591410773#L700-L702) with:

```bash
$ source ~/virtualenv/python3.6_with_system_site_packages/bin/activate
/home/travis/.travis/functions: line 109:
/home/travis/virtualenv/python3.6_with_site_packages/bin/activate: No 
such file or directory
The command "source ~/virtualenv/python3.6_with_system_site_packages/bin/activate" 
failed and exited with 1 during .

```

Yet the Bionic builds [have no problem](https://travis-ci.org/ferdnyc/openshot-qt/jobs/591407611#L848) with that same command. (Ignore the final status, they’re currently failing for different reasons.)

---

<div class="post-metadata">

**Author:** ![native-api](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/native-api/32/430_2.png) [@native-api](https://travis-ci.community/u/native-api)\
**Post date:** [September 30, 2019, 12:31pm UTC](https://travis-ci.community/t/language-python-with-system-site-packages-failing-in-xenial/5261/2 "2019-09-30T12:31:24Z")

</div>

> [@Python 3.6 and 3.7 with system\_site\_packages enabled fails to activate on xenial](https://travis-ci.community/t/python-3-6-and-3-7-with-system-site-packages-enabled-fails-to-activate-on-xenial/1697/2):
>
> You don’t. "System site-packages" is only a thing for Python versions provided by distro – which for Xenial are [2.7.12](https://packages.ubuntu.com/xenial-updates/python) and [3.5.1](https://packages.ubuntu.com/xenial/python3). 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 solu…

---

<div class="post-metadata">

**Author:** ![ferdnyc](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/ferdnyc/32/2277_2.png) [@ferdnyc](https://travis-ci.community/u/ferdnyc)\
**Post date:** [September 30, 2019, 9:07pm UTC](https://travis-ci.community/t/language-python-with-system-site-packages-failing-in-xenial/5261/3 "2019-09-30T21:07:25Z")

</div>

@native-api

Aha. So… I’m not 100% clear, since it was _Travis_ that upgraded Xenial to 3.6 (according to the banner notice above the build output) — does that mean _they_ broke their own `system_site_packages` virtualenv config?

Because, I didn’t select any specific Python version in my config, i just used `language: python` and `virtualenv: system_site_packages`.

(I do have `python3` in my apt packages list, but that reported):

> `python3 is already the newest version (3.5.1-3).`

So it didn’t actually affect anything.

But Travis’s configs seem to be expecting the default Python version to be 3.6, when in reality the distro default is still 3.5, as you note. I did nothing to specify Python 3.6 as the version to use.

(I guess I _can_ specify 3.5, though, if that’ll fix this. I’ll try that. Thanks for the info!)

---

<div class="post-metadata">

**Author:** ![ferdnyc](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/ferdnyc/32/2277_2.png) [@ferdnyc](https://travis-ci.community/u/ferdnyc)\
**Post date:** [September 30, 2019, 9:12pm UTC](https://travis-ci.community/t/language-python-with-system-site-packages-failing-in-xenial/5261/4 "2019-09-30T21:12:57Z")

</div>

Yup, manually specifying the Python version for each distro sorted it out:

```auto
matrix:
  include:
    - name: "Ubuntu 16.04 Xenial"
      os: linux
      dist: xenial
      python:
        - "3.5"
    - name: "Ubuntu 18.04 Bionic"
      os: linux
      dist: bionic
      python:
        - "3.6"

```

Now `virtualenv: system_site_packages` works as expected. Thanks @native-api!

---

<div class="post-metadata">

**Author:** ![native-api](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/native-api/32/430_2.png) [@native-api](https://travis-ci.community/u/native-api)\
**Post date:** [September 30, 2019, 10:48pm UTC](https://travis-ci.community/t/language-python-with-system-site-packages-failing-in-xenial/5261/5 "2019-09-30T22:48:24Z")

</div>

Actually, making `system_site_packages: true` imply the distro-provided Python version can be a valid feature request.  
(The potential problem I already see though is _which_ of the provided versions it should imply.)