[chirp_devel] Python 3 status
Joe Pizzi
Fri Aug 20 19:53:02 PDT 2021
Thanks, Martin, for the synopsis.
Thanks, Dan, for the input and discussion.
I created my git repository because I couldn't figure out how to do anything
in Matthew's repository. I'm more than willing to abandon my repo.
After updating my copy and creating my repo, I essentially abandoned it
myself. I took the latest Chirp from Mercurial, and started checking what
was and wasn't working when running Py3. I kinda gave up on that, too.
I started enhancing the GUI to try to bring it up on par with the GTK one,
but ran into some really strange issues.
I lost motivation when I asked several questions here in the list, and never
got any answers.
Joe Pizzi
-----Original Message-----
From: chirp_devel-bounces at intrepid.danplanet.com
<chirp_devel-bounces at intrepid.danplanet.com> On Behalf Of Dan Smith via
chirp_devel
Sent: Friday, August 20, 2021 6:51 PM
To: chirp_devel at intrepid.danplanet.com
Subject: Re: [chirp_devel] Python 3 status
> In my opinion, what would really need to happen is:
>
> 1. Do a proper migration of the Mercurial codebase to Git, preserving full
history. Make a clear note of the (Mercurial) commit at which this was done,
for later reference. (The right thing would be for the Mercurial repo to be
tagged at this point, but that seems unlikely to happen.)
This is assuming we're going to move to github, which is at least not a plan
currently. I personally don't like github, and there are several developers
here comfortable with the mercurial process and who have contributions to
chirp that outweigh a lot of perceived benefit of moving to a "new"
platform. Of course I'm 100% git in my day job outside of chirp, but I don't
want to screw over the existing contributors. I also definitely do not want
to have the github page be the thing that "regular" users find or try to
file bugs against.
> For completeness, the other alternative is to start again, from the Chirp
trunk instead of the py3 branch, and do a Python 3 migration *without*
retaining Python 2 compatibility. Also a huge task, but I have to wonder if
the result would be better in the end, and much cleaner as a codebase for
the future. In my opinion, Chirp should be *moved* to Python 3, without all
the complicated work involved in supporting both Python 2 and Python 3, and
all the additional developer effort, and testing, that would be involved
with that on an ongoing basis.
This is easy to say, but it's just not that simple. We can't stop chirp
development for two years while we completely rewrite the GUI (again?) and
sort out the immense number of unicode/bytes violations in all the drivers.
So, we have to be able to keep releasing on python2 from the main branch
while we get something on python3 close to ready - at least close enough to
be able to replace the current distribution for most people. Especially
since (almost) nobody other than myself ever works on the GUI, it's just a
huge disincentive to go in that direction at all, IMHO. The py3 branch was
being sync'd from the default branch regularly while I was working on it,
which wasn't too terrible, but it's definitely work and it's hard to get
casual contributors to make sure things work on both for submissions. Rick
probably wants to strangle me (more than usual) right now.
I spent a ton of time working on the py3 stuff for a while, but pretty much
burned myself out on it. When the flatpak stuff came it became harder and
harder to justify the extra work because it's easy for most linux users to
just use. The apple silicon thing is obviously a problem, but they're a
smaller group than linux users. Since the python2 stuff is still installable
by PPA, it's just really difficult for me to justify working on it. I know
it's a looming problem.
If there was someone committed to bringing the new py3 GUI up to parity with
the current one at least, that would help incentivize me to work on
publishing builds from that other branch and keeping the other branch synced
up. If we got to the point where the GUI was reasonably close, and most/all
of the drivers worked, then obviously switching over and abandoning the
python2 branch would be the thing to do. However, lots of people show up
here with big plans, but it rarely pans out :/
I definitely agree that the various trees that have sprung up with no
history is causing confusion, and I really don't want to see that as I think
it benefits nobody. I guess if it would help for me to create a master
github clone that tracks the mercurial tree (at least for a while) I can do
that, but I don't want to orphan the people that actually contribute via the
current process for several people that have made a couple tweaks via
github. No offense. Hopefully at least that would create a stake in the
ground for the "official" chirp git tree, with history, and then we can see
if the heavy contributors here are comfortable moving to that.
--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
More information about the chirp_devel
mailing list