Isolate our python3 use from system

[dougbu]

Motivation

System-provided versions of python3, pip, and some Python packages (certifi comes to mind) constrain our ability to bump Python package versions when necessary. Our cryptography saga was a good example of this and more should be expected. Taking us forward proactively will cost significantly less than continuing as we have been.

Business objectives

This small epic groups the work necessary to avoid these constraints — to the extent possible. The checkboxes below are steps toward that goal rather than individual objectives.

• Isolate ourselves from the system's use of python3, pip, and so on
  • this may be a breaking change for those customers using python3 themselves
  • however, the only visible change will be fewer system-installed Python packages (python3 will remain)
• Use the latest available python3 version on each system
• Install the latest available python3 version for each system
  • separate from previous checkbox because installing a newer python3 version on its own won't change much
  • also, use the latest available pip version for the python3 version on each system

Potential future steps

Optionally (not covered by an issue at the moment), …

• build python3 downloads to fill gaps in the above
  • necessary only if we decide remaining pip constraints are too burdensome
• bump our Python packages as much as possible, given remaining constraints on each system
  • interesting if we want to be proactive or think current versions were pip-limited
• remove all older python3-related OS packages from linux.yaml
  • interesting in general but problematic if our customers are using python3 themselves

One pager

TBD

[dougbu]

we're putting this on a shelf for a bit. my focus is #376 along w/ @riarenas. discussed w/ @ilyas1974 and @markwilkie but may not have mentioned this decision elsewhere…

[markwilkie]

I wonder if there's overlap here with the docker effort. cc/ @davfost @epananth

[dougbu]

maybe @markwilkie but I'm doubtful. this is about helix-scripts/ and related bits, none of which we run w/in containers

[dougbu]

Tempted to move the remaining work here (just #465 if you ignore the optional work) into either Improve helix-machines Infrastructure or under one of the Operations labels. There isn't that much work remaining and I might prioritize bumping our Python and pip installations to supported versions (we're pretty far behind) over some compliance or security work coming in from other directions. Thoughts @markwilkie or @garath and @ilyas1974 (as our fullest-time Ops leads)❔

The main problem here is I've got a branch and draft PR that represents a bunch of work but isn't ready for either transfer to someone else or pushing over the line in a day.

[dougbu]

Sub-issues #436 and #1371 are now closed. We have a bit more work to do for Docker scenarios (see #4756 fix) and #465 remains open.