Any operating system distribution - and Tribblix is no different - will have a bunch of packages for python modules.
And one thing about python modules is that they tend to depend on other python modules. Sometimes a lot of python modules. Not only that, the dependency will be on a specific version - or range of versions - of particular modules.
Which opens up the possibility that two different modules might require incompatible versions of a module they both depend on.
For a long time, I was a bit lax about this. Most of the time you can get away with it (often because module writers are excessively cautious about newer versions of their dependencies). But occasionally I got bitten by upgrading a module and breaking something that used it, or breaking it because a dependency hadn't been updated to match.
So now I always check that I've got all the dependencies listed in packaging with
pip3 show modulename
and every time I update a module I check the dependencies aren't broken with
pip3 check
Of course, this relies on the machine having all the (interesting) modules installed, but on my main build machine that is generally true.
If an incompatibility is picked up by pip3 check then I'll either not do the update, or update any other modules to keep in sync. If an update is impossible, I'll take a note of which modules are blockers, and wait until they get an update to unjam the process.
A case in point was that urllib3 went to version 2.x recently. At first, nothing would allow that, so I couldn't update urllib3 at all. Now we're in a situation where I have one module I use that won't allow me to update urllib3, and am starting to see a few modules requiring urllib3 to be updated, so those are held downrev for the time being.
The package dependencies I declare tend to be the explicit module dependencies (as shown by pip3 show). Occasionally I'll declare some or all of the optional dependencies in packaging, if the standard use case suggests it. And there's no obvious easy way to emulate the notion of extras in package dependencies. But that can be handled in package overlays, which is the safest way in any case.
Something else the checking can pick up is when a dependency is removed, which is something that can be easily missed.
Doing all the checking adds a little extra work up front, but should help remove one class of package breakage.
No comments:
Post a Comment