Python 2 should be marked as depreciated and not completely removed from the repository

We’d like to clarify if it will be possible to access Python 2 content after it has be removed from the upstream Clear Linux releases in 2020, for instance by specifying the release in swupd (similar to what you can do in Debian/Ubuntu repositories) or in a different manner?

Our company needs this mainly due to the fact that we’ve been running for a very long time on heavily integrated Python 2 software such as Caffe Deep Learning Framework that we can’t detach from at the moment. It’s mainly the backend that’s utilizing this which can only be accessed through a bastion host or a API that’s running through a proxy server, this means that the only way to access our backend is by sending a HTTP request to our strict API.

We believe that backwards compatibility and ease of use is a important factor for the continuity of this Linux distribution. By this we mean that robustness/reliability are two very important factors and removing widely spread content from the OS is not a good indicator of long term support and usability from a company’s perspective.

Thanks for any feedback regarding this.

you can always install python 2 by yourself.

Have you considered containerizing your application? Might be worth the work (and you get some host portability to boot).

Short answer: No. We will start removing Python2 as per the announcement, and at that date, when you update, Python2 will be removed from your systems.

Longer answer: You have several options available, but all of them come at some cost (you could extract the latest python content from ClearLinux build repos, or compile from source, or use a different prebuild version from someone else). However, all of those assume that python2 remains functional in the future, and given that python2 will receive no more patches, this is extremely risky.

While I understand your predicament, we can not ship software that is no longer receiving security patches. That is a hard stop. You should discuss this with the software teams that you’re consuming software from, as they are undoubtably going to see that all of their users are going to want their software to work with python3, and voicing that concern is much more productive than asking people to not delete python2 from supported software repositories.

Think of it as a car mechanic: you can’t make a car run if there’s no more spare parts on the market for it. At some point you will have to tell customers that you can’t give them a guarantee of your work because either your insurance company will cancel your shop’s insurance, or you will have customers with broken down cars blocking the entrance to your company. Both are bad for everyone, and deadly to the business.

I’ve also seen that some software is trivially adapted for python3. 90% of the work can be done by tools like 2to3 and similar.

Also, please let’s make one thing clear: Python2’s long term support plan was already established when ClearLinux was started as a project. Everyone, including the whole caffe team, knew when the plug was going to be pulled on it.

3 Likes

Thanks for the replies @doct0rHu, @castrojo and @ahkok.

Naturally you have valid points and we could compile the required libraries manually once they’re removed but what we want to empathize in this thread is how bad of a practice it is to remove content rather than marking it obsolete/depreciated and letting the users decide on their own if they wish to use it despite security/compability issues. This is deal breaking for a lot of companies and long term running systems in enterprise environments like AWS Cloud which we’re utilizing. One day someone might apply updates without prior knowledge of a bundle being removed, Python2 in this case and swupd will remove all the bundle requirements from the system and ultimately render the entirety useless. Yes, updates are first performed in a duplicate development environment in our case but we’re looking at the general picture and how things might turn out in the future if you’ll continue removing depreciated content.

Wouldn’t a real repository system like the one Debian/Ubuntu offers with backwards compatibility be more reasonable for a project of this scope that’s oriented around cloud/servers? We’re really scared about the way you’re approaching this and we hope you have some plan in mind for companies like ours which relies on older software and ease of use.

Once again thank you for your time.

You assume that someone will be supporting that.

The python community doesn’t support python2 anymore. The ClearLinux team can not support it any further. If you do find someone that is willing to support it, my estimate is that it will cost money.

Well, I can definitely state that the ClearLinux project is not going to support software that has reached the end of its life cycle. We regularly reject requests for software that doesn’t meet our maintenance criteria (regular releases, security patched when needed, etc), and we certainly will remove software that stops being supported. If this doesn’t meet your expectations, then you should reconsider using ClearLinux altogether.

One of the biggest underlying problems is that it’s increasingly difficult to offer multiple versions of python on the same system and make them work properly. This is purely interesting for a few select customers who are procuring software from vendors who are unable to update it, and therefore the problems are is attributable to their own software choices. We can’t take on the cost of those poor software choices for free - there simply are no resources in our team to support that model, and we’ve never intended for us to provide such support. Instead, you should contact companies like MontaVista that have offered commercial and specialized software support for people who need it. (https://mvista.com/en/about_press/detail/montavista-software-announces-commercial-support-for-clear-linux-os)