I have 3 projects I am working on that are checked out in origin/py3. Can I push them real quick, is there a way to move them to master, or do I just need to recreate them?

I left py3 in place because there's at least one PR in progress there. However, if you do:

$ gh pr create -B master

(or just don't do -B py3 actually) it will create the PR against master, which should work fine. It might need a rebase, but I can do it for you.

--Dan

I already "don't do -B py3". I use the web interface. So I suppose that in that case I would "don't do the selection of 'py3' from the drop down list" and leave it set to master. Right?

Yup! Just give it a shot, we'll figure it out one way or the other. I should have known you'd have something ready to go to be the first test :)

--Dan

The thought just occurred to me, since you are in the process of shuffling these branches around, will the work I am doing interfere with you in any way? Should I take a break until you have the process handled? I'm not doing anything that needs to be done right away.

Nope, the branches are shuffled. Having some stuff merged after the branch will help test the build process tonight to make sure it picks the right branch, includes all these changes, etc.

I've got other stuff to do, but nothing that conflicts with this!

--Dan

Charlie Li via chirp_devel wrote:

and multi-select/copypasta doesn't work properly under wxPython (which to me is a showstopper).

I mostly take this back, although the multi-select cut/copy-paste workflow is still clunkier than with the GTK interface. Sometimes whilst seemingly selecting then cut/copying multiple memories, only one actually ends up in the clipboard (and by extension pasted).

Hey Dan,

Following up, I have no problem with maintaining the other distribution methods and I see you have a python3 wheel posted now, so really the other distribution methods aren't a necessary evil anymore, aside from those wishing for auto-updates (snap) or a more portable solution (appimage). We'll see what happens with flaptak -- I'm not really sure what the benefit is there.

At any rate, I looks like you're missing a depenency on python3-requests in your setup.py file ;) CHIRP doesn't get past the check-for-new-version function without the requests module.

Also, will you be re-adding the `share/` directory back into the repo? Pieces there are used in the AppImage, specifically the chirp.png. If you want to keep your repo clean of non-source files that's perfectly fine. I can just add what I need from the python wheel.

Thanks, Tony

December 27, 2022 at 6:08 PM, "Dan Smith via chirp_devel" chirp_devel@intrepid.danplanet.com wrote:

...

The snapcraft, appimage and flatpack recipes will all need changes to reflect the new dependencies. Dan have you started updating the flatpak recipe?

I have not.

...

I know it's baked into your build process but assume it's just commented out for now.

It's just a jenkins job in a queue, and I haven't recreated that for the new py3-based flow.

...

If you haven't I'll gladly take a look and get it into shape and would love to have it in the git repo so anyone can create their own flatpak for other architectures (like arm and such)

Yeah for sure, I was kinda expecting you would continue to own that, with my gratitude of course :) If you can submit what you need, I can integrate it into the build process. I figure that for the moment, being much easier to install on Linux without heavy lifting was "good enough" for power users looking to be on the edge. But enough people seem to like the flatpak (at least) that it's worth us doing that going forward. And when I say "us" I mean "you, if you're willing" :)

Thanks Tony!

--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers

Ah there it is. Thanks Charlie! I should have been more thorough.

Now that just leaves the missing dep on python3-requests.

Tony

December 29, 2022 at 8:54 AM, "Charlie Li via chirp_devel" chirp_devel@intrepid.danplanet.com wrote:

Tony Fuller via chirp_devel wrote:

...

Also, will you be re-adding the `share/` directory back into the repo? Pieces there are used in the AppImage, specifically the chirp.png. If you want to keep your repo clean of non-source files that's perfectly fine. I can just add what I need from the python wheel.

share/ is under chirp/ and included in MANIFEST.in so they are already included in the wheel. It is necessary that they are included with the source so that importlib_resources can reference those files properly and that the bdist installs properly. This will be more strictly enforced when full PEP-517 compliance happens.

-- Charlie Li …nope, still don't have an exit line.

---

chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers

How are you generating your python3 wheel? I'm getting an error from pip when it tries to auto generate the wheel.

Like this:

$ setup.py sdist bdist_wheel

Here's what I'm seeing when snapcraft tries to install CHIRP:

• pip install -U .

... Building wheels for collected packages: chirp, future, yattag ... WARNING: Built wheel for chirp is invalid: Metadata 1.2 mandates PEP 440 version, but 'daily-20221229' is not ... Failed to build chirp ... DEPRECATION: chirp was installed using the legacy 'setup.py install' method, because a wheel could not be built for it. pip 23.1 will enforce this behaviour change. A possible replacement is to fix the wheel build issue reported above. Discussion can be found at https://github.com/pypa/pip/issues/8368

I don't really care that python packaging people think that I should use a version number of the format they chose. It's an application, not a library, built by date, and without any semver guarantees.

If this becomes a problem then the non-bundled version will need to use a different version from other things, like 1.0.20221225 or something, but until and unless that becomes a hard requirement I don't think it'll be doing anyone any good to be confusingly different. As noted before, 98% of the users consume the bundled builds, and with as many people are using the flatpak type builds (which I'd put in a similar category), that's probably >99%.

--Dan

Dan Smith via chirp_devel wrote:

...

Here's what I'm seeing when snapcraft tries to install CHIRP:

• pip install -U .

... Building wheels for collected packages: chirp, future, yattag ... WARNING: Built wheel for chirp is invalid: Metadata 1.2 mandates PEP 440 version, but 'daily-20221229' is not ... Failed to build chirp

What's in between the first warning and the failure message? Warnings are just that, and I've still managed to build sdists and bdists despite them.

...

... DEPRECATION: chirp was installed using the legacy 'setup.py install' method, because a wheel could not be built for it. pip 23.1 will enforce this behaviour change. A possible replacement is to fix the wheel build issue reported above. Discussion can be found at https://github.com/pypa/pip/issues/8368

I don't really care that python packaging people think that I should use a version number of the format they chose. It's an application, not a library, built by date, and without any semver guarantees.

If this becomes a problem then the non-bundled version will need to use a different version from other things, like 1.0.20221225 or something, but until and unless that becomes a hard requirement I don't think it'll be doing anyone any good to be confusingly different. As noted before, 98% of the users consume the bundled builds, and with as many people are using the flatpak type builds (which I'd put in a similar category), that's probably >99%.

Many packages just use <year>.<month>.<day> outright for this reason, and it still fits PEP-440.

Tony Fuller via chirp_devel wrote:

The full build log for the snap might be more interesting than posting the output from pip in this thread. https://launchpadlibrarian.net/643304763/buildlog_snap_ubuntu_focal_amd64_e0... https://launchpadlibrarian.net/643304763/buildlog_snap_ubuntu_focal_amd64_e0fec5d9b363f11b29818f8f9274f735_BUILDING.txt.gz

I get the feeling that pip says "error" but doesn't mean "fatal error", if such a distinction still exists today. Pip does continue to install CHIRP (using the legacy setup.py which I think will break soon)

So after wxPython failed to build with the current setuptools, it fell back to 44. That might be too old for us, although it appears to have worked despite the failure message. In any case, setuptools recommends pinning their dependency to 58 for those projects still using setup.py, since after that such functionality became collateral damage whilst implementing more of PEP-517 support.

Additionally, farther down the log, you don't need to copy all of chirp/share, since they are now part of the package and referenced accordingly via importlib_resources. The only files that should get installed into the respective hierarchy directories are chirp.desktop to share/applications and chirp.png (and maybe chirp.svg) to share/pixmaps (or whatever icon directory).

One question, is there not a man page now, or have I missed something?

There's this:

https://github.com/kk7ds/chirp/blob/master/chirp/share/chirpw.1

Which I guess needs to be updated/renamed. I'll add that to my list, but if anyone else wants to submit a change, that'd be cool.

--Dan