pip.rb: python3 get-pip.py

[cclauss]

As requested by @native-api at travis-ci/docs-travis-ci-com#2413 (comment), now that Python 2 is end of life, let's use Python 3 to install pip.

What is the problem that this PR is trying to fix?

Python 2 is end of life so we should no longer default to pip installing Python packages with it.

What approach did you choose and why?

Install with Python 3 which is the present and future of the language instead of Python 2 which has been legacy for years and is now end of life.

How can you make sure the change works as expected?

This is has been common practice for years.

Would you like any additional feedback?

If not now, why not??

[native-api]

Would it be possible to instead create pip, pip2 and pip3 that would correspond to python, python2 and python3?

• get-pip.py only creates an unversioned pip executable. So python would be referring to a 2.x while pip -- to 3.x. There was a recent complaint at exactly this inconsistency: https://travis-ci.community/t/python-is-python2-7-but-pip-is-pip3-6/8165

• The switcheroo will break existing code and contradicts the distro's conventions so it will be counterintuitive. Let's make the switch the same time as the distro does. 20.04 is due in a few days.

• Pip is still supported for 2.x, and will continue to be for as long as practical despite the EOL: https://pip.pypa.io/en/latest/development/release-process/#python-2-support

[cclauss]

[This] contradicts the distro's conventions

Nonsense. The bionic manifest is clear that Python 3 is part of the distro and Python 2 is not. There is a similar situation for all other major Linux distros. Sorry but legacy Python is a dead parrot. The Python 2 sunset date was postponed numerous times over the past decade but now its EOL date passed. The laziness needs to stop because everyone had 14 years to port their code. If they have not completed that port then the code in question must not have been important.

When a mainstream CI system like Travis continues to default pip to Python 2 (against the distro's conventions) that profoundly effects the PyPI statistics in favor of Python 2 and to the determent of Python 3. This gives the false impression that the transition to Python 3 is going slow when in fact that transition is already complete.

So please stop saying that the distro's conventions favor Python 2 when Python 2 is not even on the distro's manifest. And stop saying that the default pip should point to an EOL piece of software. It is giving a false impression that significant progress has not been made by the Python community.

python2 -m pip should be the method that Travis recommends that Python 2 packages are installed. It forces the acknowledgement by the user that they are invoking a end of life system and that they are taking full responsibility for all associated security risks.

[native-api]

Okay, let's get this straight. Travis does not encourage -- or discourage the use of Python 2. It simply replicates the distro. Users expected Py2 to be there in current Linux images when each of them was introduced and it's too late to change that now.

Likewise, Py2 available as python by default simply because it is in the distro -- so users expect it to be the same here.

The bionic manifest is clear that Python 3 is part of the distro and Python 2 is not.

That list only shows what is present in the downloadable image. Please do not make any wild assumptions based on that as I'm not going to respond to bogus claims again.

In particular, Py2 is very much present in the Desktop image and its manifest; and despite Py2 not being installed by default in Bionic, it's still Py2 (if it's installed), rather than Py3, that is available as python.
The accusation that this shows that the distro "favors" Py2 is your personal conclusion. It may as well be for maximum compatibility with existing code to smoothen transition to Py3, for example.

When a mainstream CI system like Travis continues to default pip to Python 2

Corresponding pip to python (regardless of what that "python" happens to refer to) and pipX to pythonX is codified in https://www.python.org/dev/peps/pep-0394/#for-python-runtime-distributors (para. 5) -- which Ubuntu follows.
So on the contrary, breaking that would be "against distro conventions".

that profoundly effects the PyPI statistics in favor of Python 2 and to the determent of Python 3

Yes, it sucks when things don't go your way. Blame Ubuntu maintainers if that makes you feel better -- as I've shown, this is simply the result of providing an image based on this specific distro (as opposed to, say, RHEL which ditched unqualified python altogether).

Or help in making Py3 Pip easier to use out of the box -- in a way that's in line with distro conventions! The easier it is to use out of the box, the more users will use it!

[cclauss]

You are right. I am wrong. My apologies.

Do you support the integration of something like #1055 so the distro facilities the installation of current Python packages?

[native-api]

Is this actually necessary? If yes, why only run it for one of the pips?

[native-api]

These will break in Focal (it only provides python3, with an optional package symlinking python to it) but are still needed for images for older releases.

We can fix that when we get there though (in particular, we don't know if Travis will be providing the optional symlink), so not insisting on addressing this in this PR...