In our project, we work across multiple operating systems, and our goal is to create a background daemon to perform OS-related tasks such as tracking CPU processes and user activity.
Here’s a list of operating systems that we have and its compatible Python versions:
Windows XP - py3.4
Centos4 - 2.4
RHEL 7.x - Py2.7
Question: How should we determine the appropriate Python version? Should we opt for the lowest supported version for compatibility? That is, 2.4?
If we go with higher python version, how can we deploy the application across different OS environments?
That’s a nightmare, Is there any way we can use python 3.x?
My end goal is to deploy a application to all the os.
Is it possible to implement using py 3.x and create a application which bundles everything together including all the libraries together in higher OS and then deploy it, so that my application will work in all the OSs irrespective of lower versions
You might be able to use embedded python and write a thin executable that just calls python scripts with the correct parameters.
However, running such unsupported OSes is a terrible idea completely independent of the python version and is probably going to cost your company a lot of money at some future point if these are in any way connected to the internet and/or mission critical - depending on where it the world you are it might literally be illegal for companies to use OSes with known vulnerabilities. (or there are plans to make it illegal, don’t recall the exact details right now)
You could try to maintain your own builds of a suitable python 3.
But watch out for issues because of compiler support for the python code. Also betting hold of the old version of dependencies.
And you cannot allow any of this code to ever connect to the public internet for security reasons.
The nightmare should be raised with your management.
Correct, Even if I install python 3.x, the glibc libraries in the OSs are outdated, I have to upgrade those also.
To make it compatible with lower versions of OS, I have to built in the lower versions, right, But I couldn’t as I can’t install higher version of python
All of those OS versions are themselves out of support, so you’re largely going to be on your own. (RHEL 7 went out of full support in 2019 and out of maintenance support in 2024, but still has extended support. The others, far as I can tell, don’t have any upstream support.) This is the kind of plan where there are no right answers, only different choices of what kind of manual work you’re going to have to accept. Not one of those is something that I would recommend for an internet-facing server, with the possible exception of RHEL 7 (and even that only until you can get around to upgrading it).
So my real recommendation is to get off those ancient OSes and get onto something newer. You’re only inflicting unnecessary pain on yourself by restricting to what they can do. But if you absolutely cannot change that, then install a very recent Python on the Unix systems (build from source if you have to), and Python 3.4 on XP, and resign yourself to a lot of unnecessary hassles on Windows. It’s an ancient and unsupported Python on an ancient and unsupported Windows, and you will have no end of problems.
But really, get off those old OSes. This is not something worth sticking to.
Then find the person who has the permission and tell them that the company is very likely liable for problems that come about as a result of running an unsupported OS. And make your request in writing (eg by email). Then one of two things will happen: Either approval will be granted and you’ll finally get onto something decent, or your behind will be covered and the person you spoke to will be the one who’s holding the bag when something inevitably breaks.
Congrats. You now have double the work, since you will have to make all changes in two places.
Whoever’s in charge of the OS decision, be sure to inform them that everything done on this codebase is costing twice as many billable hours (or salaried hours or whatever you’re working on) to accomplish. Actually, maintaining 2.7 compat is probably even more than double, since you are going to have to think about all kinds of issues that you won’t have to worry about if you had a 3.12-only codebase.
Do some arithmetic. Work out how many dollars this decision is costing the company. Then put a presentation together and get onto a newer OS.
I’ve raised the OS concerns shared by you all, so let’s hope for the best,
Also, until then, we plan to go with the common Python compatibility version possible across all OS, which is python3.4 until the OS issue is resolved
In this case, what’s your recommendation/what are the challenges we face if we upgrade the python version from 3.4 to 3.12? like dependency compatibility issues?
Make sure that you have very good test coverage of your code and application logic.
You will have to re-test as you move from version to version. Having very good test coverage will save you a lot of time.