SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Even if python2 is unmaintained and not seeing patches, it should be available just in case. There are a lot of random python scripts that people have written for various things and porting them to newer versions will be much harder if you can't verify functionality first under python2. Anyone who was writing scripts before version 3 probably has a personal archive of old scripts that would be worth running, even if just for the nostalgia.
It's really not just a matter of dependencies. A lot of companies rely on python for internal scripting purposes. If you take away python2 you take away the abilty to pull a script out of the archives from 10 years ago and run it. I'd rather spin up an isolated machine off the network to run an old script than not be able to run it at all. Even in a perfect world where everyone stopped writing in python2 and moved to python3 at the same time, on schedule, it would not change the fact that someone, somewhere, has to make python2 available for historical purposes. Some of these newer devs keep forgetting that Linux is popular on LTS systems that run for decades at a time.
Even if python2 is unmaintained and not seeing patches, it should be available just in case.
If it is pulled out of Slackware, it is highly likely that someone will add it on SBo. That way if people need to use it, they can still install it, but it just won't be installed by default.
But Pat has not made a decision yet (at least not that he's announced publicly), so it's anybody's guess as to what would happen. But there's already been issues with upgrading software in -current because of python2. I guess the newest python-pygments removed python2 support, so any programs that depended on the python2 module in Slackware were broken. Pat reverted it to a previous version that still had python2 support for now, but he did ask for input on what people's thoughts were on keeping or removing python2.
Here's his note in the changelog:
Code:
l/python-pygments-2.5.2-x86_64-1.txz: Upgraded.
It seems like the pragmatic thing to do here is to revert this one to fix
the python2 programs and modules that depend on it. We'll have to do a bit
more research to determine what the best course of action is regarding
python2 in general, though. Certainly we shouldn't be requiring python2
for anything important moving forward, but even that will take some work.
Plasma 5 as currently built has multiple dependencies on python2, for
example.
Assuming the the dependencies can resolved in the base install to not require python2, I wonder if python2 would belong in extra/ or pasture/. And honestly, IMO it's probably still early to make that call. Python is a full programming language, so it's not like we all need to stop dealing with it the moment some devs say they want to move on to 'the future'. If 15.0 had python2, but all the symlinks defaulted to 3.x I wouldn't be all that upset.
Why do we need to add new and remove old at the same time? Maybe the removable of python2 should wait for a later slackware version? In terms of an LTS cycle, it's more like a transitional period where both versions are available. As long as both versions can coexist then it seems like a logical next step.
Is it worth keeping python2 if we need to limit versions of certain programs? This has already happened with python-pygments. If the next dev cycle takes another few or more years until we get a stable release, having programs held back could cause compatibility problems in the future. Just imagine if 14.2 had kept an older version of Xorg to ensure that the AMD proprietary Catalyst driver could be installed.
If all of Slackware can be recompiled to not require python2, then it should simply be removed from a stock install. Sure, I suppose it can go in extra/ or pasture/, but why not just let SBo pick it up? That way if there are patches or upgrades (whether official or 3rd-party), the SlackBuild maintainer could easily push those out.
Even if python2 is unmaintained and not seeing patches, it should be available just in case. There are a lot of random python scripts that people have written for various things and porting them to newer versions will be much harder if you can't verify functionality first under python2. Anyone who was writing scripts before version 3 probably has a personal archive of old scripts that would be worth running, even if just for the nostalgia.
1. That's really no-one's problem or responsibility but your own
2. I'll bet that well over 90 percent of those scripts will work fine in Python 3 after you change the print statements
3. If you really need a Python 2 installation to support your proprietary, closed-source software (and that's really what we're talking about here), then you can build one. Or set up an older distro in a VM if you need Python 2 packages that aren't trivial to build (PyGTK, PyQT, Tensorflow, etc).
As long as both versions can coexist then it seems like a logical next step.
This was the "logical next step" in 2015 when it was made clear P2 was sunsetting and P3 would replace it. Now P2 is truly and absolutely dead. No security patches, no updates. It's puzzling that this narrative is emerging that there's some mad dash to kill P2 or obstinate devs who refuse to compromise by life-supporting P2 until forever.
The reality is that if something is still not python3-ready now, another grace period won't help.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.