[Distutils] Any thoughts on supporting e.g. Alpine Linux? (was: PEP 571: Any further manylinux2010 concerns or questions?

Trishank Kuppusamy trishank.kuppusamy at datadoghq.com
Mon Apr 2 12:45:17 EDT 2018

Hi Brett, Donald, and Nick,

Thanks for your replies!

On Sat, Mar 31, 2018 at 11:06 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> The main reason PyPI doesn't currently support distro specific wheels is
> because there isn't a compatibility tagging spec for them that's reasonable
> to use on a public index server - they currently end up being tagged as
> generic "linux" wheels. You can live with that on a private index server
> like the one that https://galaxyproject.org/ runs, but it would be
> incredibly confusing on PyPI.
> As far as I know, https://mail.python.org/pipermail/distutils-sig/2015-
> July/026617.html is still the most complete write-up we have of a
> potential way to fix that, which is to:
> 1. extend the default Linux platform tag to include the ID and VERSION_ID
> fields from /etc/os-release (credit to Galaxy Project's Nate Coraor for
> that core concept)
> 2. define a config file under /etc/python/ that distros can use to change
> both the build tag (e.g. allowing CentOS users to emit RHEL compatible
> wheels, or Ubuntu users to emit Debian compatible ones), and a list of
> binary compatible distro tags (e.g. allowing CentOS to consume RHEL tagged
> wheels, Ubuntu to consume Debian tagged wheels, and other musl based
> distros to consume Alpine tagged wheels)
> 3. define an equivalent per-virtualenv file to override the settings from
> (2)
> 4. update pip/setuptools/twine/warehouse/etc to account for the new
> compatibility tag variant
> One useful aspect here is that older clients will just ignored the new
> tags as "not a match", which means there shouldn't be any significant
> backwards compatibility hurdles.
> Honestly, I think the main benefit of heading down this road will be to
> allow folks to cache their custom wheel builds more effectively, so I'm not
> especially worried about making it generic (beyond the platform level
> config file suggested above).
> That said, if there were to be a significant growth in non-manylinux Linux
> wheels on PyPI, I'd expect them to be for the official Docker Inc base
> Python images, which are Alpine based, and hence can't use the glibc-based
> manylinux binaries.

I think this is a good idea, especially given that manylinux1 and
manylinux2010 wheels won't work on the official Docker image for Python.
What does everyone else think?

If we wanted to contribute towards this effort, how can the community help,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180402/044579d1/attachment.html>

More information about the Distutils-SIG mailing list