[14:28:09] I want to fail the test if we don’t get the latest version of all these packages
[14:34:02] In fact is there a way to list all the packages you have installed with available updates, and those you can upgrade to and those you can’t?
[15:02:30] <McSinyx[m]> I think there’s a way, but not solely using pip
I’d like a command that shows me what packages I can/can’t upgrade and why, that has an exit code that can be used in CI for checking that all the packages are the latest version with no conflicts
I’ve personally only used mousebender in internal applications, but the client logic is so straightforward I’m quite confident both libraries got it right.
Incompatibility means multiple things in Python packaging. A package that does not satisfy dependencies of other currently installed packages can be simply downloaded and inspected without installation. Binary distributions (wheels) have static metadata that can be read directly. Source distributions are more problematic; PEP 517 has a hook to generate only metadata without compiling the whole package (prepare_metadata_for_build_wheel), but not every package implement the compilation well to support that. I believe importlib.metadata supports reading from .whl out of the box, and has privisional support for prepare_metadata_for_build_wheel.
I’d use the pip-tools package pip-compile command to get a resolved list of transitive dependencies and their versions, and then check that each of those is the latest version available.
Note though that this is going to be fairly slow, and you might have problems where e.g. IPython has dropped Python 3.6 support (good on them!) but you still have some CI jobs running on those older versions.