Python 2.7 on FreeBSD 14.2 before migrating to Python 3

W

WrinkledCheese

Hey all,

Eventually I'd like to get the code migrated to Python 3, but getting up an running asap is step 1.

Background: I worked for a software company between 2011 and 2019. 2019 they shut their doors. Earlier this month, they asked if I wanted to do some work for them and get the old software running. In 2019 we were running FreeBSD 11.1. We maintained packages using poudriere. Currently, I'm having issues getting the software to work properly as it's using HTTPS since the Let's Encrypt CA certificates were renewed in 2020, the old ones don't work. I tried updating the ca-root-nss.crt certificate using the current 14.2 release ca-root-nss package, but that didn't work. I was able to install it - it's only a plain text file with a bunch of CA root certificates afterall - and copy it to the 3 or 4 other places that use a copy, eg /usr/local/share/certs, /etc/ssl, and a few other places I'd have to look up again. Anyway, the certificate works if I visit from a modern system eg. Windows 10 laptop. However I need to be able to deploy the software to FreeBSD and the FreeBSD 11.1 systems can't validate the certificate. Rather than trying to figure out an outdated, EOL'd, OS's issues with certificate validation, I want to deploy the software to a modern version of FreeBSD. This is why I want to install Python 2.7 modules, that don't seem to exist on the pkg ecosystem.

I'm currently setting up a newer poudriere using a newer 14.2 FreeBSD, from which the custom software can be deployed along with a FreeBSD 14.2 package set. I imagine I can manually track down each Python 2.7 version of the libraries I need, but I was wondering: Is there's a quicker way of tracking down the few dozen py27-* packages I need? Or will I have to just hunt down all the python 2.7 packages manually? Eg I need pycrypto - renamed to cryptodome for "Crypto" and cryptodomex for the newer "Cryptodome" library, but all I can find via pkg is py311-pycryptodome.

Ultimately updating the software to use Python 3 would be optimal, but getting up and running as soon as possible and then updating the source is the ideal order of operations.
 
WrinkledCheese said:
... I want to deploy the software to a modern version of FreeBSD.

... but getting up and running as soon as possible and then updating the source is the ideal order of operations.
Click to expand...
Those two goals are each in isolation good and laudable. But I fear they may conflict with each other. The answer to this contradiction is likely not a technical one, but a sociological one: You may need to negotiate to either run on an obsolete (and therefore insecure) version for a while longer, or to do the re-engineering for Python3 before bringing it back up.

And please point out to your customer: We have known since 2008 (!!!) that Python 2 will become obsolete and non-usable around 202x. So they have ignored over a decade of warning. And just to soften this harsh-sounding criticism: I just ported my last package that is in continuous use last summer.
 
Transitioning to Python3 can be non-trivial with the subtle literal string changes and its dynamically typed nature, though.

Better rewrite it in Rust :)
 
cracauer@ said:
Transitioning to Python3 can be non-trivial with the subtle literal string changes and its dynamically typed nature, though
Click to expand...
Thanks for that simple explanation. Have you ever seen such breaking changes in a programming language between versions?
As a learner it make me wonder if it's worth learning. Maybe Python 4 will break everything again?

It begs a layman to ask. Why did they not change the name instead of breaking the ecoculture.
ralphbsz said:
We have known since 2008 (!!!) that Python 2 will become obsolete and non-usable around 202x.
Click to expand...
~15 Years was a pleanty of notice but why break it. Such a weird move. We talked about C++ standards evolving versus C standards that retain backwards compatibility.
This is worst case scenario it seems.
 
Phishfry said:
Thanks for that simple explanation. Have you ever seen such breaking changes in a programming language between versions?
As a learner it make me wonder if it's worth learning. Maybe Python 4 will break everything again?
Click to expand...

The magnitude of changes is not greater than what other languages went through. It is just that you have no compile-time checking APIs to detect changed APIs before you run, and that the string literal issue is essentially uncheckable except by a human trying to understand the original programmer's intent.

It has seriously undermined my trust in the language.
 
I was going to recommend to the OP to just resurect the python27 port like JMOS did for his SeaMonkey port build. I am sure the distfile is still in place.
But the OP also mentioned several other py27 modules and that could get to be a rabbit hole.
Plus the time spent trying to make py27 work is lost time. But in a pinch I can understand.
For SeaMonkey it was only a build time depends.
 
cracauer@ said:
The magnitude of changes is not greater than what other languages went through.
Click to expand...
Remember the transition from K&R C to ANSI C? From Fortran IV to 77? I was there for both of them, or on the tail end. There is a reason on the mainframes we kept both Fortran compilers around for a decade: Old code in IV would not run correctly in 77. Both transitions were painful. And in all these cases, the changes in the language were incompatible, were done for good and logical reasons, and the new design choices are simply much better.

But as you said: In the case of compiled languages, 99% or 99.9% of the changes are caught at compile time, so once the code compiles, it is very likely to "just work". In the case of an interpreted language, there is no such compiler. For Python, the automated tools like 2to3 handle 90% of the changes (the print function, the "as" needed in exception catch statements), and for much code, the string -> unicode conversion makes no difference. But the problem is in that in an interpreted language, even good linters can not find the last 10% of corner cases. For example, sometime people build up python statements in strings (or read them from config files), and then exec or eval them. There is little any automated tool can do to help here, since there isn't even a "source code" for those statements.

I actually reach the opposite conclusion: I think carrying lots of ancient cruft and incompatible language around for a long time makes a language much worse. For example, in today's C++ or COBOL, there are several different coding styles, depending on when you learned the language. There are C++ source files that a modern programmer (accustomed to auto variables and move semantics) won't understand, while a programmer stuck in 1999 C++ won't even be able to read modern code. Similarly, someone who grew up in the era of "ADD A TO B GIVING C." will not like seeing "COMPUTE C = A + B.", and vice versa. To keep that balkanization under control, it's better to deprecate old versions, with a decade or so of warning.

So I applaud the Python community for having the fortitude to create a better language, and be willing to get the unavoidable criticism when people have to clean up their dusty decks.
 
ralphbsz said:
I actually reach the opposite conclusion: I think carrying lots of ancient cruft and incompatible language around for a long time makes a language much worse.
Click to expand...
Well, "my" opinion is different.
If backward compatibilities are somehow hurted, the project (here, python) should "officially" hand-over the maintainership to whom (hopefully anyone already authorized member of the project) willing to maintain, and simply fork as another different language.
Or provide "compatibility mode" or another "language processor" (interpreter or compiler) supporting old language spec with new code base.
 
By the way, lang/python27 is already deprecated and expired, but still has a plenty of dependencies, thus, could not be removed from ports tree.

According to FreshPorts, 7 ports require it to build and 2091 ports require it to run. On the other hand, 2154 ports are already deleted because of BUILD_DEPENDS and 2083 because of RUN_DEPENDS to lang/python27. Note that this does not mean 4237 ports are deleted, as some could depend on both build and run.

And there can be a candidate for supercedeng python 2.7.
Can lang/tauthon usable as an alternative?
It seems to be maintained (not actively, though, seems to be about once an year or so) and having disclosed github repo.

Anyway, I myself don't want to use Python directly, though.
 
You must log in or register to reply here.
Back
Top