packaging VS cryptography

> You can't use wheels

musl wheel support was added some time ago:

https://github.com/pypa/packaging/releases/tag/21.0

No idea how many packages actually build musl wheels though. From a quick glance at least cryptography and lxml has musl wheels.

Python supports Alpine just fine; indeed, the standard Docker Python images include Alpine variants.

If you mean binary wheels, PyPA packaging added support for Alpine wheels a few months ago (https://github.com/pypa/packaging/pull/411), and auditwheel support for the same just shipped today.

You can use the packaging module to compare versions. It's used by setuptools so you probably have it already installed. The the rest is pretty straightforward imho:

Congratulations to the authors, this was a feature that was dearly missing from pyca/cryptography. It took a long time to get right.

For the history: https://github.com/pyca/cryptography/issues/2381

Some context:

- The cryptography dependency used by the current release of mitmproxy has a CVE related to an OpenSSL vulnerability (https://github.com/pyca/cryptography/security/advisories/GHS...)

- The main branch of mitmproxy has already upgraded to the latest version of the cryptography package

- The author of the package does not believe the CVE impacts users of mitmproxy so a release including this commit has not been made

Also you'll use https://github.com/pyca/cryptography

first, I did see a correlation between an endpoint being heavily hit in a given time window, and an increase of memory usage that didn't went down afterwards. The endpoint didn't do much so I went through every instruction - is a global variable appended indefinitely ? Is a cache decorator growing without a limit set ? Do I use a 3rd party that has a known issue ? Turns out, it was using cryptography, so I looked up known issues. Saw an issue about a leak when using load_pem_x509_certificate https://github.com/pyca/cryptography/issues/4833 - which I used ! I could fortunately just upgrade the library

Après le kerfuffle du paquet de cryptographie cette semaine (https://github.com/pyca/cryptography/issues/5771), J’ai passé en revue l’état des outils de gestion des dépendances en Python.

> A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs.

One thing this is missing is that Rust is useful for libraries callable by many different languages. You may or may not want to use it to build an actual Web app (I personally think it's a solid choice, but reasonable people can disagree). But for building, say, the Python cryptography library [1], which is used as a part of "webcrap" and Jupyter notebooks, Rust is clearly an excellent option. Nobody is going to build core Python infrastructure in Go or Node, and there will always be a need for plumbing libraries.

[1]: https://github.com/pyca/cryptography

Also, I see more and more examples where rust gets included in different technologies using FFI. Ie for python https://github.com/pyca/cryptography for security/performance critical pieces.

> I am curious. Could you give some more context?

Probably talking about this: https://github.com/pyca/cryptography/issues/5771

You will be hard pressed to find a cryptography library that doesn't depend on openssl. Fortunately openssl bindings can be installed on Windows. One of the more popular libraries for python is cryptography, but it does depend on libssl.