Another option is to use a containerized app delivery mechanism like flatpak. Then you can pin to a runtime containing Python 2, build the app, and not mix app artifacts/dependencies with those on your system.

I have such a build here. Note that it hasn't been updated in a while, and I'd recommend building it locally vs. installing from the flatpak repo which may no longer work:

Unfortunately I don't think Flathub wants non-versioned builds, which is why I never contributed it there. It may also be possible to automate the builds, but I gave up on that. Happy to accept contributions from anyone willing to take this work further. Alternatively, maybe it can be integrated into CHIRP's own build infrastructure? Ideally a Python 3 port can happen at some point, but until it does, flatpak/snap will probably be better distribution channels.

On 11/18/19 2:36 PM, Jim Lieb via chirp_devel wrote:

I upgraded one of my desktops from F30 -> F31 last night. The system upgrade 
downloader refused because dependencies for chirp were no longer present. In 
order to continue the upgrade, I first removed chirp.

After the upgrade I then attempted to (re)install chirp and found that it is 
not in the F31 repositories. A little research found chirp stuck in the update 
queue. In other words, it didn't make the gate for F31 release and will 
continue to have problems due to its dependence on Python 2.


The following is the  most recent testing log output of the Fedora build 
system:

.... cut here ....

results:
- arch: x86_64
checkname: dist.rpmdeplint
item: chirp-20190812-1.fc31
outcome: FAILED 
scenario: x86_64
type: koji_build


conflicting requests: nothing provides python2dist(future) needed by 
chirp-20190812-1.fc31.noarch
conflicting requests: nothing provides python2dist(future) needed by 
chirp-20190812-1.fc31.noarch

.... cut here ....

This is a failure for both the x86_64 and armhfp builds. Package python2dist 
has been dropped as part of the Py2->3 changes as best as I can see. This 
leaves two choices:

1) The packager (hobbes1069) changes the build to use what is left of Py2 in 
Fedora. This is chancy because Python on Linux/UNIX is not friendly to mixing 
system objects and local (user built) objects. Not to mention that Py2 is an 
upstream zombie at this point.

2) Chirp gets a Py3 workover so it can fit into the new universe. I know there 
has been some Py3 effort but I see nothing (yet) in the Hg repo.

Note that this would also be a problem for a private build from source as 
there is no Py2 infrastructure left in the distro, meaning one would have to 
do a whole Py2 local install (/usr/local) and then hack bits so that chirp 
uses that while not breaking system "stuff" base on Py3 such as dnf, the 
package installer.

I have also attached the latest relevant Python 2 email from the Fedora team.
This relates to the FTBFS message above.

_______________________________________________
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