Bring back good 'ol python 3.6

[gtristan]

Centos7 still uses Python 3.6, this is more relevant than 3.6 being considered EOL by upstream python.

Lets try to get better support.

[juergbi]

As I understand it, Python 3.8 can be installed on RHEL/CentOS 7 using rh-python38 from Red Hat Software Collections 3.8. I.e., Python 3.8 is officially supported on RHEL 7 to a certain extent and users should really upgrade to this if they can't upgrade to RHEL/CentOS 8 or 9 yet. Is my understanding not correct?

Also, I expect that Python 3.6 support would cause issues over time, if not already. Python libraries tend to drop support for obsolete Python versions, which make the latest versions uninstallable. I.e., I'd prefer not merging this, if we can avoid it.

[gtristan]

As I understand it, Python 3.8 can be installed on RHEL/CentOS 7 using rh-python38 from Red Hat Software Collections 3.8.

Trying to verify this, "Red Hat Software Collections 3.8" doesn't appear to be something accessible for Centos 7, for centos there appears to be "The Software Collections ( SCL ) Repository" installable with yum, but despite rumors on the internets indicating that this would contain rh-python38, it does not appear to be the case as far as I can see.

I'll keep spelunking for a bit, and will likely just resort to using a BuildStream 2.x which supports python 3.6 since this appears to be the path of least resistance, in this case I'll try to make sure the magic wheel also gets built, use that directly, and we can discuss separately whether or not to merge this.

Also, I expect that Python 3.6 support would cause issues over time, if not already. Python libraries tend to drop support for obsolete Python versions, which make the latest versions uninstallable. I.e., I'd prefer not merging this, if we can avoid it.

I think you're talking specifically about the frozen set of dependencies we use for testing.

It's happened a couple of times that I've come right up to the edge of giving up on that and accepting that we need separate frozen requirements.txt for each supported python version rather than expecting that we can force all python versions to support a fixed set of dependencies, this approach does not seem to be viable (especially with frequently breaking grpc versions and the constraints we need to place there).

[gtristan]

As I understand it, Python 3.8 can be installed on RHEL/CentOS 7 using rh-python38 from Red Hat Software Collections 3.8.

Trying to verify this, "Red Hat Software Collections 3.8" doesn't appear to be something accessible for Centos 7, for centos there appears to be "The Software Collections ( SCL ) Repository" installable with yum, but despite rumors on the internets indicating that this would contain rh-python38, it does not appear to be the case as far as I can see.

I'll keep spelunking for a bit, and will likely just resort to using a BuildStream 2.x which supports python 3.6 since this appears to be the path of least resistance, in this case I'll try to make sure the magic wheel also gets built, use that directly, and we can discuss separately whether or not to merge this.

Conclusion here is that it is not installable from centos-sclo-rh, even if all evidence to the contrary exists on the internets.

The issue here probably is that it would require a yum update to refresh everything and get access to new packages which include the rh-python38-python package, which I'm not yet certain would be acceptable to do in this specific centos7 based build container image.

I may resort to building/installing python 3.8 from source here as a less disruptive option.

Also, I expect that Python 3.6 support would cause issues over time, if not already. Python libraries tend to drop support for obsolete Python versions, which make the latest versions uninstallable. I.e., I'd prefer not merging this, if we can avoid it.

I think you're talking specifically about the frozen set of dependencies we use for testing.

It looks like it's even worse than I expected... attempting to get buildstream to build/install on python 3.6 requires additional reverts in buildstream, and I've encountered some errors (indirect dependency of ujson -> setuptools_scm) which don't seem feasible to work around, at least not with an automated pip install.

Likelyhood of dropping this PR altogether is raised exponentially ;-)

[nanonyme]

I'm strongly against merging this. It's not really supportable to maintain support for Python 3.6 anymore. Instead, you should probably recommend running Docker container for obtaining BuildStream 2 for CentOS 7. Any developer would be using a newer distro than that. For build servers containers are the most plausible option.

[nanonyme]

@gtristan you can't have the cake and eat it too. EOL Python version means BuildStream dependencies and build dependencies have dropped support for it. If you want to support CentOS 7, make RPM's and backport fixes. You will then need to become a downstream maintainer of BuildStream.

[nanonyme]

This will happen again soon. You have to be mentally prepared to drop support for Python 3.7 and figure out how to handle it.

[nanonyme]

One possible way is branching BuildStream such that 2.0.2 is not allowed to drop support for Python versions but 2.1.0 can. Then you can maintain 2.0 through branch and backport fixes and tag releases separately.

[nanonyme]

To make it more obvious, Python 3.7 EOL happens next Summer and it is very probable this project's deps will stop testing and caring about it towards next Winter. You can't randomly drop support for Python versions so you will need policy which versions can drop support for Python versions.

[gtristan]

Indeed the situation is even more dire than I suspected, it seems to be extremely difficult to get these dependencies to cooperate once python 3.6 has been EOL for a very short number of years :-/

Closing this.

[nanonyme]

At least we're not using Rust or the problem would be much much worse.