I see that back in May 2019, work was done to get os8-run working under python3.

I've just checked in updates to os8script.py.in and simh.py.in, and now I have a successful end-to-end clean build under python3.

Although I'd personally planned never to leave python2, I've had to accept the reality that everybody is shifting to python3, and many platforms and environments are deleting python2.

We should formulate a plan for migrating to python3.

I shall attempt to investigate the answer to question #1. Unfortunately, I broke python2 on my Mac, which is why I troubled myself to get the python3 branch building.

Sorry for the delay in moving this forward. I've had varying amounts of energy to devote to mentally strenuous activities.

I realized that I had a perfectly good python2 environment on my pidp-8/i!

It also had a python3 installed that was detected with the updated auto.def, so I made the following hack:

pi@pidp8:~/src/pidp8i/os8-run-python3 $ fossil diff -c auto.def
Index: auto.def
==================================================================
--- auto.def
+++ auto.def
@@ -0,0 +469,5 @@
+
+# temporary hack: crowbar python2 for testing.
+set pyver 2
+set pycmd "python"
+

The resulting config and build seemed to pass 100%!

There was one log line in config that I will check on:

Cannot test-os8-run: fix with 'sudo cpanm --installdeps .'

I ran the proffered cpanm command. It takes a while on a Pi3B. But now I get:

Python 2 is installed here as 'python'.
Python module pexpect is installed here.
Python module pkg_resources is installed here.
All test-os8-run prereqs available here.
Generated adrules.mk for src/cc8/cross, src/d8tape, src/misc, src/palbart, src/pidp8i, src/SIMH, src/SIMH/PDP8.
src/config.h is unchanged

where previously I got:

Python 2 is installed here as 'python'.
Python module pexpect is installed here.
Python module pkg_resources is installed here.
Cannot test-os8-run: fix with 'sudo cpanm --installdeps .'
Generated adrules.mk for src/cc8/cross, src/d8tape, src/misc, src/palbart, src/pidp8i, src/SIMH, src/SIMH/PDP8.

Who else has a python2 environment that we could ask to do a test build before merging this back into trunk?

The resulting config and build seemed to pass 100%!

Cool!

Cannot test-os8-run: fix with 'sudo cpanm --installdeps .'

It's just warning you that test-os8-run can't be used until you install the dependencies it needs.

While re-generating media images with os8-run is a useful test of the port to Python 3, you already get more than one of those with a fresh build of the software. I don't see what building yet more media images does in regards to validating the port.

Who else has a python2 environment that we could ask to do a test build before merging this back into trunk?

Probably the next step is to try porting everything to Raspbian Buster. If that works, then it's time for a release, if only as a way for those wanting OS images to get a current version of Raspbian along with the PiDP-8/I software.

The whole point of making sure we're ready for Python 3 is that I'd guessed that Buster would ship without Python 2 readily available, but it looks like I'm wrong about that.

Do we want to add a static option to enable forcing python2?

I'm not sure what next action step I should take.

Is merging the os8-run-python3 back into the trunk ok to do now?

Do we want to add a static option to enable forcing python2?

I'd need a practical use case.

Even testing doesn't count, since that implies that Python 2 compatibility going forward is an important goal. We can argue about where the cusp is, but there's no question that Python 2 use will continue to decline.

Your hacky patch above is the forcing option, if you like.

The branch is integrated now. It's the best way to be sure that the new functionality gets fully tested.

Incidentally, I did my own testing on Buster:

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 10 (buster)
Release:	10
Codename:	buster
$ uname -a
Linux pidp8i 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux

Sounds fine to me. I figured I'd ask the question by way of due diligence.

Great. Then the issue is closed. I see you've closed out the tickets about python3 too.

A recent change to the top-level README.md expresses some of the ideas in this thread.

It previously just said we depend on pexpect, but that implied that we don't have an explicit dependency on Python, only on this one library. Python isn't installed by default everywhere; you need to make sure Python is installed, then install pexpect. Perhaps this is needlessly pedantic?

It now sets down our stance on the 2 vs. 3 issue. Do you agree with my wording?

We can't leave this implicit, since some may interpret silence as meaning that we intend to support Python 2 indefinitely. Python 2 is dead; it just hasn't stopped twitching yet.

Our sensible options then are to abandon 2 in the next release or continue as the README.md file now claims. You'll be carrying a lot of that load, so which do you prefer? Given the support cutoff for Python 2 earlier this year, I'm leaning toward requiring Python 3, but if you want to continue maintaining backwards compatibility...

I like your wording.

Although the world is moving on to Python3. It's not yet a problem to maintain Phython 2 backwards compatibility. I'm taking time to get comfortable with the notion of requiring Python 3. I'm not there yet.

Your wording captures my current mindset quite well, actually.