Language: python with system_site_packages failing in Xenial

Environments Xenial
, ,
1

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:

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 with:

$ 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 with that same command. (Ignore the final status, they’re currently failing for different reasons.)

2
1 Like
3

@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!)

4

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

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!

1 Like
5

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.)