Hacker News new | ask | show | jobs
by bredren 1733 days ago
There was a thing in February where Python cryptography required rust, which broke docker-compose installs via pip. [1]

There was a fair amount of back and forth about version pinning—it affected a lot of builds.

Even the issue on the crypto package about it was fairly tense. Iirc, the dependency was rolled back.

[1] https://github.com/docker/compose/issues/8105#issuecomment-7...

4 comments

The Rust was not rolled back from cryptography. The new version of wheel and pip now use the precompiled wheel package for cryptography. Therefore, installing that package does not require the Rust compiler in Docker. However, this does not guarantee that the installation of other Python packages with Rust will also run smoothly.
What it does still do is make pyca/cryptography incompatible with niche architectures that were previously supported but are unsupported by Rust (due to lack of support by LLVM).

The OpenWrt community learned this the hard way.

> were previously supported

I think it was over this debacle, definitely over some debacle, someone made a great blog post that pointed out this wording is usually incorrect (edit: Link https://blog.yossarian.net/2021/02/28/Weird-architectures-we... HN Thread: https://news.ycombinator.com/item?id=26294397).

It previously worked, but no one was promising support for niche architectures. It just happened to work (at least enough that there weren't obvious bugs, who knows if fully). Expecting support for every non-standard way you can use the software is usually not a reasonable expectation of maintainers.

I'm familiar with the argument.

A functional c compiler on a platform is one of the oldest, basest assumptions that package maintainers make. This is a good thing for open source in general and not something that should get tossed aside lightly.

A functional C compiler on the platform means that your software is in the realm of possible and that somebody interested enough might help maintain it.

The alternative presented is "lol screw you". Not by these thoughtful posts, but if you look at the sentiment of the threads like when this happened in pyca/cryptography.

> Iirc, the dependency was rolled back.

I am fairly certain it was not, e.g. see this comment (or just notice that there's still rust code in the codebase)

https://github.com/pyca/cryptography/issues/5771#issuecommen...

(Edit: Changed link to a better one)

(I'm one of the cryptography authors)

We did not roll back our dependency, no, although our current release (3.4.x) allows you to disable Rust compilation via an environment variable specifically so we could understand where in the ecosystem challenges would occur. Our next release (now 35.0 based partially on feedback from the community around our unusual versioning) will hard depend on it for all X509 ASN.1 parsing. During the months since we did our first rust release, however, the `musllinux` specification and implementation has been finished so we expect to be able to ship binary wheels for Alpine very shortly. I am actually working on that today, with the only remaining blocker being an update to warehouse to allow wheel upload.

I think I ran into this problem while trying to Dockerize ansible to be able to run on ppc64le.

For other reasons, I have a need to be able to run an up to ansible on Linux on POWER. I think due to a lack of an available wheel for cryptography on ppc64le, I ended up having to include cargo in the dependency chain and subsequently a pretty large docker image (over 200MB). Ugh.

You can avoid this by building cryptography as a docker stage and then just extract the wheel as part of your docker build process. Alternately if you install rust, build cryptography, and uninstall rust all in one layer then you can also avoid this issue.
That's what I currently do already but I did notice that I failed to uninstall gcc when looking at the Dockerfile again today so I'm now down to 150MB (after rebuilding). Still not great but better.

Currently my build uses Ubuntu, I'm going to try switching over to Alpine when I get a chance to see how much savings I can claw back.

I believe you should be able to avoid docker image size bloat by combining `install rust; do things that need rust; uninstall rust` into one run directive (same with anything that needs any compiler). It's not a runtime dependency.
You're aware that Python doesn't support Alpine?

The reason is that python is meant to run on Linux systems with glib, but Alphine has musl instead. It's a common source of compatibility issues not limited to python.

Note that pip wheels are only specified and only built for glibc compatibility, so the limitations extends to all python packages.

I don't understand why rust integration doesn't happen on a fork, especially for important packages like this. I'm sure people would elect to use py-cryptography-rust and it woule avoid an open-goal from people looking to seize on a rust-related headline in bad faith.