[chirp_devel] Future patches for python 3?

[Dan Smith]

> ===== Fundamental issues =====
> PyGtk (unmaintained) only supports python 2
> - PyGObject looks good, easy to migrate, but only supports GTK+3.x.
> There might be a visual difference from GTK+2.x
> - There's a compatability shim, but it is far from perfect
> 
> Py2exe (unmaintained) only supports python <=3.5
> - Use old python on windows, patch it, or use an alternative?

We have to have a path forward here, and running python2 only on windows doesn't seem great. If pygobject works with gtk3 on py2 and py3 equally well, then it's a start I guess, but it gets us more fractured than we are today, even with distros threatening to drop py2. There are easy ways to install/package things on linux to maintain a py2 environment on those distros, but having users running with bleeding edge py3 on other platforms and py2 on windows seems like it's going to be a larger gap to me.

> Thing is that the changes that need to be made are neither small nor
> self-contained, so I'd like to at least give a heads up to the current
> maintainers (hi Dan!) and make sure work isn't duplicated if anyone is
> working on this already.

Several people have stated they were going to do this, but nobody has circled back with something to look at thus far. I don't have the time (or desire) to work on the conversion, but I don't want to stop anyone else from doing it. I _do_ worry a lot about creating instability for very little gain (IMHO) given we're mostly in "add new drivers" mode these days.

If we could maintain an hg branch that gets rebased often, with stable builds from default and testing builds from the py3 branch, that seems like it would be better until confidence rises. I'll happily do the work to make both builds and help with messaging to users to try to get people to help test.

> Any particular comments about things they do/don't want to see would
> be great too. My current plan is:
> 1. Work on the GObject problem first. If desired, I can keep the
> original PyGtk code working in parallel, but I think that will cause
> confusion in the long run. Be prepared for one monolithic patchset.
> Still python 2 code.

We're going to need some serious review and testing of something like that, and I imagine it's going to be pretty gnarly as a single monolithic blob. Just fair warning :)

> 2. Work out any hidden issues that GObject has, ensure packaging
> works, etc. I hope there will be nothing here that isn't caught by
> review but experience has taught me otherwise...

I feel like the potential for gremlins will be high, so I'd definitely like to be able to build from another branch and encourage users to help chase out the bugs.

> 3. Add disabled-by-default python 3 testing.
> 4. Fix things until tests work under python 3
> 5. Enable testing on python 3 by default (in addition to testing on python 2)

Running both when I generate a build is easy, so no worries there.

--Dan