installing pyqt5 (qt version 5.15) on python 3.8.5 and jetpack 4.4

Back in September 2019 I wrote how I failed to build Qt 5.13 from its C++ source, which was the latest Qt release at that time(see https://arcanesciencelab.wordpress.com/2019/09/02/an-absolute-failure-unable-to-build-qt5-on-a-raspberry-pi-4/ ). My primary reason to build the latest Qt was to step up the Qt version used in PyQt5. There were problems I’d discovered in the installed repo version, and I’d wanted to create a development environment where I could investigate, and if possible, try to fix any of those problems, with an eye towards pushing any fixes back up stream. That obviously didn’t work out, and I left the whole thing alone. Until now.

For whatever reason I decided to try again. Except this time, I used JetPack 4.4 on the Nvidia Xavier NX Developer Kit. While the Xavier is ostensibly for machine learning prototyping and development, the fact it’s based on Ubuntu 18.04.5, ported onto Nvidia’s six core ARM chip, makes it too tempting for me just to use for ML. And thus I decided to try to run with the latest PyQt5 on the latest Python 3 release.

Installation

I’m starting from my Python 3.8 installation inside an activated Python virtual environment. I’d documented how to build Python from scratch as well as create a working virtual environment here: https://arcanesciencelab.wordpress.com/2020/05/24/building-python-3-8-3-on-jetpack-4-4-dp-and-the-jetson-xavier-nx/ , so I won’t go through that again.

However, before we really get started, you’ll need to install the basic Qt5 development tools, otherwise PyQt5 won’t install. You do that with sudo apt install qt5-default . That gives all the basic tools and support libraries.

With Qt5 default installed, activate the Python 3.8 virtual environment. I’ve since moved up to Python 3.8.5, and I’m getting ready to install Python 3.9 alongside 3.8.5 when it’s officially released. That’s another reason I like virtual environments; it’s incredibly easy to keep multiple Python versions on hand.

Within the virtual environment, do a simple pip install pyqt5 .

You might as well go off and do house work or watch an episode or two of your favorite streaming shows, because this is going to take a while (as in hours). No, I didn’t time it.

Once it’s done, it should announce it’s successful. From there you can work with PyQt5 within that virtual Python environment. I would strongly recommend you always work within a Python virtual environment. It all works with your regular security permissions (no sudo), and if you want to blow it away, it’s very easy to do so. I just don’t like adulterating the system installation of Python anymore.

So far, except for the long build time, everything is working without any drama.

reinstalling jetpack 4.4 official on the jetson xavier nx

I reinstalled JetPack 4.4 on my NX. It wasn’t like I had a choice in the matter. A couple of nights back I picked up the latest Ubuntu 18.04/L4T updates, and when it rebooted, it refused to come back up. After all that work playing with it, and with no backup, I pulled the current image from the Nvidia website and started over again.

Which was, in hind sight, actually a Good Thing. The Developer’s Preview had picked up a bit of cruft from all my experimentation. Being forced to recreate the boot image wasn’t all that horrible, it just cost me a detour and a chunk of my time I really didn’t want to have to give up.

It wasn’t all that bad, actually. After all, you flash a micro SDXC card, poke it into the NX, and apply power. Fortunately for me the bits I cared about were on my blog, and I used my other Linux notebook to basically copy my home directory to a 64GB thumb drive, from which I cherry-picked the bits I want to move over to the new install.

One of the oddball problems I ran into was re-installing Deno. On the 4.4 Developer’s Preview I’d installed Deno via Rust’s cargo, and got Deno version 1.0.2 up and running. This time, Deno had moved up to version 1.1.3 and failed to build via cargo. I’ve gotten Deno back by pulling the source tarball off of Deno’s github site. I discovered what the cargo build failure was by watching the source tarball build: The module deno_lint is 0.1.16 from cargo, and it fails all over the place with unresolved calls. The module deno_lint in the source tarball is version 0.1.15, and it builds. After the build, I pushed my binary over to ~./local/bin (which is in my path) and carried on using Deno.

Oh, and I pulled the latest Emacs from their git site, and I’m now running with version 28.0.50. Some things are actually a smidge better with this release.