[chirp_devel] Future patches for python 3?

[Jake Merdich]

On 11/26/2018 4:55 PM, Dan Smith via chirp_devel wrote:
>> ===== 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.

No kidding. I'm all for a homogeneous system at all times (except for 
very clearly 'experimental' branches and maybe an XP-only build). 
Stability and maintainability should be king.

My opinion is that Python 2 should remain the default on all platforms, 
with Python 3 being separate and experimental until we're completely 
certain it is stable, and then it should be a clean switch with a major 
release. It does look like Fedora will support Python 2 applications for 
at least a few more years (they wanted to remove unused py2 libraries).

Also, py2exe does seem to have some good replacements, but that's a 
topic for another day. Python 3.5 is still under support.

>> 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.

I understand the problem of flaky new contributors, but I hope I break 
the trend and get this done, and I'm very committed to not shipping 
broken code.

FWIW, I do have the pygobject code about 80% done, with mostly corner 
cases and packaging left. All basic functionality works, but I'll still 
be testing until I have personally tested every line of code in the UI 
folder (~69% now) and find no difference in functionality. There should 
be a patch coming and builds for people to break some time this week.

I'd be completely on board with keeping this in a branch until it's 
proven stable.

>> 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 :)

Bring the pain!

The diff will be mostly line-for-line identical in its logic, but 
gtk2->gtk3 has renamed a LOT of things.

>> 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.

Again, agreed.

>> 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 _______________________________________________ chirp_devel
> mailing list chirp_devel at intrepid.danplanet.com 
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer
> docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
> 

Thanks for looking into this, and here's to 2020-proofing the code!

Jake