Hacker News new | ask | show | jobs
by codethief 1903 days ago
Case in point: "Using Alpine can make Python Docker builds 50× slower", https://pythonspeed.com/articles/alpine-docker-python/
2 comments

That article should be titled, “Most Python packages do not upload an Alpine-compatible wheel to PyPI.”

If you know where to find Alpine-compatible wheels, or host your own, Alpine has no build-speed penalty.

Where do you find Alpine-compatible wheels? Many ones uploaded to PyPI aren't, because e.g. both GitHub actions [0] and Azure pipelines [1] don't have Alpine images. Is it reasonable to expect maintainers of small, open-source libraries to write and maintain their own Alpine runners?

I guess if you know your company's workflow depends on Alpine, you can build and cache them yourself. But the wider community doesn't benefit from that.

[0] https://docs.github.com/en/actions/using-github-hosted-runne...

[1] https://docs.microsoft.com/en-us/azure/devops/pipelines/agen...

I was not aware of prior work so I maintain Alpine wheels for packages I use personally in a GitHub org.

https://github.com/alpine-wheels/index

Besides my own needs, only one other person has requested additional packages, which I was happy to add. Maintenance is minimal, mostly just approving pull requests created by Dependabot.

That's pretty slick! Thanks
Exactly zero packages upload Alpine-compatible wheels to PyPI.

The manylinux specification assumes glibc, so there is no valid distribution format which would allow the publication of non-glibc wheels.

However there is an in-progress PEP to support it: https://www.python.org/dev/peps/pep-0656/

I've used alpine images for python in production and not run into any of these issues. The key is to know how to use multistage builds to cache layers.