The major takeaway from this is: if your project is mission critical, then don't depend on free/open source infrastructure.
It's not like there is a "rep" you can call at "python" if this is now breaking your build process.
edit: almost all of these replies have missed my point. Yes, you can still use python2, but if you depended on pip for your build process (which I would consider "infrastructure"), then you are out of luck for this and there is nobody you can call to fix it for you.
Yeah, its not like you access to and the sources of all versions of Python. No proprietary vendor has ever revoked licenses, pulled downloads, version or timebombed binaries, stopped support for eol products, auto upgraded, etc.
Yes open-source is clearly worse for giving you the right and means. Vs being subject to the whims and profitability of a company.
It is literally happening right now. The people who have demanded that everybody switch to python3 instead of simply forking python have proven the FUD true.
If you want forks there are forks. Off the top of my head, Redhat is supporting Python 2 for several more years and there's a project called Tauthon [1] that is "Python 2.8" in spirit. I'm sure there's more efforts I'm not aware of.
The push for Python 3 has been happening for over 10 years at this point. At what point do you expect people to be able to stop supporting a very outdated distribution of any software?
6 years ago my company switched to Python 3.5 and there was a big push in the community at that point to move away from Python 2. I mean Python 3 came out around the same time as Windows Vista, which has been unsupported since 2017.
Good luck calling your "rep" at nearly any commercial software supplier and explaining you're using a decade-old version of their software a year past its EOL date and would they kindly provide you support.
It doesn't matter whether it's open source or not, there has to be a line on these things, and there's been more than enough time given here.
> It doesn't matter whether it's open source or not
It actually does: with open-source you are not bound to the vendor if it isn't cooperative, but can pay anyone else willing and able to do the work. Plenty consultancies will happily fix old bugs or backport fixes in open-source software for you, but can't do much about closed software you depend on.
Well, I'd say no surprises here, because as most other Open Source software / infrastructure, Python is provided under a license that offers the software as-is and doesn't promise "warranty of fitness for any particular purpose". Technically the complaint here is against pip, but I guess they have similar terms and conditions.
On the other hand, you would have enjoyed a royalty-free, world-wide permission to use, distribute, and modify the code base at your will.
So I'd say, not a bad wager if you're willing to do the extra work of keeping your software up to date over time (which otherwise you'd have been paying someone to do, in case of a proprietary infrastructure).
> Yes, you can still use python2, but if you depended on pip for your build process (which I would consider "infrastructure"), then you are out of luck for this
Using python2 is acceptable for you, but using an old version of pip is not acceptable?
My problems are largely coupled heavily into the python2 that my package manager is written in, which as far as my team tells me, is python2. And that it's becoming difficult to integrate against products we have to continue to release for another five years of corporate sunsetting.
It's not like there is a "rep" you can call at "python" if this is now breaking your build process.
edit: almost all of these replies have missed my point. Yes, you can still use python2, but if you depended on pip for your build process (which I would consider "infrastructure"), then you are out of luck for this and there is nobody you can call to fix it for you.