Use Python 3 in example

[methane]

Python 2 will be EOL at 2020-01-01. Please recommend people to use Python 3.

[BanzaiMan]

what is wrong with the current documentation? Our python builds generally use virtualenv to manage the run times, and I believe $HOME/.local/bin is a better choice than /opt/….

[methane]

what is wrong with the current documentation?

Please read this article: https://dev.to/methane/use-pip3-to-install-awscli-44pk

Our python builds generally use virtualenv to manage the run times,

Note that this is not a Python build. What is the preferred way to use Python 3 & pip on non Python builds?

[BanzaiMan]

We should fix the example if it's broken, but that should be independent of the use of Python 2 or 3.

[takluyver]

A bit more context: projects are looking at package download statistics to evaluate when it's reasonable to drop Python 2 compatibility. But for some use cases - like awscli - you can use either Python 2 or 3, with no visible difference (for now). We'd like to push these use cases to Python 3, so that the statistics show more accurately how many people want/need to run Python 2, rather than using it by default because it's what examples point to.

Unfortunately, there doesn't seem to be any simple way to use Python 3 on a non-Python build without calling pyenv. Python 3 is already present in both the trusty and xenial environments by default, but pip isn't directly usable (pip3 gives a pyenv error because there isn't a Python 3 environment active, python3 -m pip gives "No module named pip").

So maybe the first step is to tweak the build environments to make it easy to use pip on Python 3. Python tools are starting to drop Python 2 support, and I'd expect many more to do so in the next year, so this is a good time to make it easy to use Python 3.

[Pezi777]

Show available Python runtimes #1763 has been open for quite some time. @BanzaiMan Should I close this one as we have this one, too?

[takluyver]

I think that's a separate question - I don't follow it entirely, but it looks like it's about the list of Python versions available which can be specified in a .travis.yml file.

The example in question here involves using Python in a non-Python build, i.e. where you're building software in some other language, and you need some tool which happens to be written in Python.

[cclauss]

This line is now optional as xenial is the default distro.

[cclauss]

Why not just put at the top of the script:

language: python
python: 3.7

Or leave out the second line to default to Python 3.6.

[takluyver]

I think the example is meant to work regardless of the language setting, because people may want to use the technique on projects in various languages.

[cclauss]

Thanks. Now I understand. Pyenv is superslow so what about this approach which works on Trustry, Xenial, and Bionic?

- python3 -m pip || wget -qO- https://bootstrap.pypa.io/get-pip.py | sudo -H python3
- python3 -m pip install --user awscli
- aws --version  # aws-cli/1.16.217 Python/3.5.2 Linux/4.15.0-1028-gcp botocore/1.12.207

[takluyver]

No module named pip

I set up a tiny test repository to experiment with what is possible on Travis. I couldn't find any way to use pip on Python 3 without either invoking pyenv or installing pip first - I assume either of those options is unwanted hassle. Feel free to play around and see if there's something I missed, though.

So I think before this example can be changed, it would be necessary to change the default Travis build images, e.g. to include the python3-pip package.

[cclauss]

• https://travis-ci.com/cclauss/awscli-on-xenial-hack
• https://github.com/cclauss/awscli-on-xenial-hack/blob/master/.travis.yml

[takluyver]

Yup, it works if you install pip first. But I'd imagine people won't especially want an extra install-the-installer step given that the example as it stands works without that.

[cclauss]

pyenv takes a minute and a half to build Python 3. I'd imagine people won't especially want an extra slow install-a-language-that-I-don't-need-and-is-already-present step...

Also, pip install -U pip is effectively install-the-installer

[takluyver]

I mean, compared to the example as it currently is, using Python 2.

[takluyver]

I had a go at adding pip-on-Python 3 to the default images, but I don't really know the infrastructure, I just found a likely looking bit of code:

travis-ci/travis-cookbooks#1055

[cclauss]

It would be better to more explicitly use --upgrade than -U to avoid confusion because pip also has a --user option.

[BanzaiMan]

Has the new example in this PR been tested? If so, please provide a link. I also note that it should be tested under different circumstances (with respect to language, os, etc.).

[methane]

https://github.com/methane/travis-test/blob/master/.travis.yml

[cclauss]

It would be nice if pyenv in Travis was upgraded to allow Python 3.8 to work in this fashion.

[cclauss]

it should be tested under different circumstances (with respect to language, os, etc.).

.travis.yml in https://github.com/cclauss/Travis-CI-languages-by-operating-system might be a good starting point for exploration.