Platform Development • Re: I created a Python 3 port of UXP out of boredom...

Is there a way for the user to select the specific Python version to be used in the virtual environment, in mozconfig (preferrably) or wherever?

I mean, on [older] systems where the user is for some reason forced to self-build, there can be multiple versions of Python3 installed, and at some point the official sources might require a higher version than what is default for the given system; i.e. on Ubuntu Bionic and derivatives the default is Python 3.6 but there can also be any of Python 3.7, 3.8 and higher backports (up to 3.12 currently), so assuming your port would at some point require a minimum of Python 3.9 how could the user specify the Python 3.9 executable for the UXP/Pale Moon Python virtual environment?

Or would an initial script purposely scan the system for the required minimal Python3 version, and inform the user if not found?

Maybe I'm overthinking this but I believe it would be beneficial to future-proof the basis at least for as long as the UXP (and Pale Moon) sources will still compile on older systems.

Actually, I tested against a variety of versions... and I will share with you the trick I used during development. Essentially, you can just create a directory somewhere on your system with symlinks to the version of Python you want. Let's say /usr/local/bin just for example (which is what I used). In that directory, create symlinks to python3 and python that both point to your preferred Python version. Then, inside the terminal window you're using to build Pale Moon, modify PATH with something like "export PATH = /usr/local/bin:$PATH" and then you should have your preferred version of Python be the default available, since that directory will now overshadow system Python. To revert to the standard, just set PATH back to normal. If you're testing multiple Python versions that are altinstalled to the same location like I was, you can even just keep creating and deleting those symlinks and get the environment to point to different Python versions without many further changes.

So I don't necessarily think anything needs to be implemented at the build system level to achieve this.

Just so you know (and maybe feel a bit reassured), I implemented this in such a way that it should support all the way back to Python 3.4... it was mostly a result of starting off with older versions because it was easier to get older Python 3 working there and walk up through the versions because the deprecations hit in big waves that way rather than all at once (especially since I originally was trying to keep virtualenv). And also, MozillaBuild on Windows is still using Python 3.7 something, and as far as I can tell there's no real advantage to using a newer Python 3 version... I just want to support the newer versions primarily for mainstream Linux distros, but there's no reason to force people to use the latest. Everything we'll ever need from Python 3.x is in 3.4+, and my plan is to try and support newer versions in a way that doesn't break older ones if I can. Continuing to support Python 2.x would be excessive, IMO, but older Python 3 is more than doable.

It is worth remembering that this was a Python 2.x codebase originally, and that basically I only did what was needed to get it working on newer Python... there was not exactly an eager desire to take advantage of new Python features, we just wanted people on modern Linux to be able to build our stuff like they did before finger-wagging distro maintainers and Guido von Rossum's people put their collective feet down and said, "No, you can't use Python 2 anymore even if it's just for a big set of glorified Makefiles, you are going to put in two months of hard work to support our Python 3 vision, or it's either forcing people to hunt down ancient OpenSSL versions to build Python 2 from scratch, hoping people know what Tauthon is, or full-blown Docker containers for your project, and we don't care how that affects you."