[lug] Running a mixed Python environment

[Steve Litt]

On Mon, 14 Sep 2020 19:04:12 -0600
"Jed S. Baer" <blug at jbaer.cotse.net> wrote:

> On Mon, 14 Sep 2020 19:51:57 -0400
> Steve Litt wrote:
> 
> 
> > What I've been doing is converting all Python that *I wrote*. It's
> > consisted mainly of converting print commands to print functions,
> > and was pretty easy.  
> 
> I'm thinking of converting what I wrote to something less likely to
> need later work. :) I used to write my little utilities in Bash and
> Perl. They all still work without any further attention. 

If you write anything in bash more than 300 lines, you're a better
programmer than I. And bash is very slow on loops.

Contrastingly, there's nothing the slightest bit slow about Perl5. And
we all know it has the best regex on the planet. But, but, but, CPAN.
If you need capabilities beyond the base, and Perl's base isn't that
inclusive, you need to use CPAN. One time, while trying to install a
Perl shopping cart at a client's site, I used CPAN to add a library,
and it broke their Vim software, and some other pieces of their
software, and I couldn't put it back by backing out the CPAN install.

I think Perl's great for simple file and array processing, and it can
make some impressive apps (The first invocation of my UMENU software
was written in Perl in 1998). But if I had to pick the language that
most guarantees if I start the project in that language I'll finish the
project in that language, it's Python, with its spectacular set of
standard libraries. And pip isn't as wild and crazy as CPAN.

> I admit,
> finding an alternative to Beautiful Soup that's as nice won't be easy.

I understand that Beautiful Soup already runs under Python 3, but
without Python3-exclusive code. I understand that as of 12/31/2020,
Beautiful Soup will pull off the bandaid and be Python 3 only for all
new versions. So under those circumstances, it might be worth it to
figure ways to finesse Python2 libs for another year.

> 
> > As far as code written by others that hasn't been upgraded to
> > Python3, I consider such code unmaintained and seek alternatives.
> > Py2 to Py3 conversion is just too easy to be a problem for any
> > reasonable code with a reasonably competent developer(s).  
> 
> I don't believe there's any alternative to chirp, in Linux. 

Looking toward the bottom of
https://chirp.danplanet.com/projects/chirp/roadmap , there appears to
be some sort of a chirp-py3 branch. Perhaps you can find out when that
branch will be ready for prime time. If soon, keep finessing.

I don't know if chirp requires connection to the Internet, but if it
doesn't, perhaps you can have a separate machine (maybe on a Raspberry
Pi 4), air-gapped from the Internet, running an old distro with full
Python 2.7x, for years and years and years. Today, by my right knee,
sits a computer I bought in 1998, with Windows 98, for those twice a
year situations in which I need to look at Micrografx Windows Draw
files. It works just as well, on 1998 software, as it did in 1998, and
it's air-gapped so nobody messes with it.

[snip]

> > > I don't have any trouble invoking these scripts under Python2,
> > > what I need is to get the modules they use where they can find
> > > them.    
> > 
> > That's understandable, but the Python project sunsetted Python 2 on
> > 1/1/2020. https://www.python.org/doc/sunset-python-2/ . What this
> > means to you is that the longer you wait to pull off the bandaid,
> > the more painful it will be. 

When I made the preceding statement, I didn't know that at least some
of your programs were soon converting to Py3, which makes a case for
keeping Py2 libs updated until those softwares go Py3.

> > Every distribution will sooner or
> > later stop supplying the deprecated and sunseted Python2x, so the
> > sooner one switches, and finds alternatives for those projects
> > refusing to switch, the less pain one will endure.  
> 
> Yeah, well, it's already a pain. Fortunately, it's still possible to
> pull the Python2 stuff down from older repos. And so far, there
> hasn't been any conflict with anything, that I've found. I ended up
> running chirp in flatpak, and installing what I needed for fslint.

I have a lot of similar problems with LaTeX stuff, and I often kludge
until pieces of software get it right. I manufactured all my books in a
Ubuntu VM for 7 months until finding a LaTeX font that didn't break my
books under the latest LaTeX. Then I went back to doing them on my
metalic machine, which was MUCH more convenient.

> 
> The thing with sunsetting stuff like this is that the people who
> decide to do the Guido aren't bearing the cost of converting. For
> some projects, the maintainers might simply not have the time to do a
> conversion. 

I get it. They have day jobs. They have families to pay attention to,
social lives to conduct, hobbies, and they need time to eat, sleep, and
do errands. But Maintainers saw this coming down the road 12 years ago.
Certainly they could (and should) have done all new construction in
Python3, redoing a section at a time. At the very least, starting
from the moment they heard there was a Python3 with print() function
instead of print command, they should have inserted into every file the
line:

from __future__ import print_function

And they should have made any added or changed code the Py3 way.

Some projects are huge, but the Python folks announced in 2008 that
they'd sunset in 2015, and eventually moved that out to 2020. That's a
few thousand days. The Python project put up the Python Countdown
Clock. This was no surprise. I can only surmise that, for certain
projects, modifying their code for Py3 wasn't a priority. Now they have
an insurmountable problem. If theirs is worthwhile and without peer,
I'm sure it will be forked and converted to Py3. Otherwise, users will
go elsewhere.

> Using 2to3 on the scripts I wrote didn't get me anywhere.

My experience was that I just went through the code looking for print
commands, and manually changed every one to a print() statement. That
usually worked, but if it didn't, I just troubleshot.

> Doing a conversion on a large codebase could be quite a problem for a
> volunteer-maintained project.
> 
> I don't think it's fair to just label these projects "unmaintained".

I think it is. What were they doing between 2008 and now? They saw it
coming. They knew the day would come when Py2.7 would be removed from
distributions. They didn't adequately maintain. 

My opinion is that it's actually worse than unmaintained. I use the
unmaintained fetchmail software 480 times a day, every day, and it's
just fine. I use the unmaintained runit init system every day (well, I
start and stop daemons pretty much every day, rebooting, not so much).
These softwares are simple, bug free, and work every time, so it's not
important whether they're maintained. Python2 apps, on the other hand,
are increasingly difficult to run on various distros, without all sorts
of finessing. 

And like I said, they had over 8 years warning, the first time.
 
SteveT

Steve Litt 
Autumn 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive