Python cryptography, Rust, and Gentoo

> It turns out that the project has its own versioning scheme, which allows this kind of change (as does semantic versioning, actually).

What's even more interesting is that the semver spec (https://semver.org) gives the following rationale for this rule:

> Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts.

Obviously, that proved to be a rather optimistic assumption in this case. On the one hand, I'm having a hard time believing that this is somehow the cryptography developers' fault. They are not in a position to tell downstream reusers how to do dependency management. On the other hand, Python's packaging system is... kind of bad at this entire problem space. In Debian, for example, apt-get update && apt-get upgrade is *mostly* safe (if using stable), and unattended-upgrades pointing to (just) the debian-security repos is almost completely safe. But pip install --upgrade can and will make a complete hash of anything and everything if you're not careful, and the simplest alternative, pip freeze >requirements.txt, is pretty much stuck at the opposite extreme of "never upgrade anything ever." So instead you have to do more complicated shenanigans with requirements and/or constraints, which basically forces you to know about every single package in your entire transitive dependency tree. Not ideal.