Skip to content
This repository has been archived by the owner on Feb 27, 2024. It is now read-only.

Enhance the platform tag definition for wheel files to cover platform variants #39

Open
qwcode opened this issue Sep 14, 2015 · 8 comments
Open

Enhance the platform tag definition for wheel files to cover platform variants #39

qwcode opened this issue Sep 14, 2015 · 8 comments
Labels
Wheel

Comments

@qwcode
Copy link
Contributor

qwcode commented Sep 14, 2015

The current definition of the "platform" tag in PEP 425 is inadequate:

  • it doesn't account for Linux distribution variations
  • it doesn't clearly indicate the Windows MSVC runtime (this is technically implicit in the CPython runtime version, but could be clearer)
  • it doesn't account for variations in SSE support (None, SSE2, SSE3), which is critical for NumPy

Since distutils.util.get_platform() isn't providing sufficient platform discrimination, we need to come up with a new definition that provides the details we need, while also allowing pip to automatically fall back to the less specific wheels if the exact variant isn't available.

migrated from https://bitbucket.org/pypa/pypi-metadata-formats/issues/15/enhance-the-platform-tag-definition-for
@qwcode qwcode added the Wheel label Sep 14, 2015
@soltanmm
Copy link

What's the state of this?

Copy link

I'm also interested in the state of this issue, especially the first of the three points (accounting for Linux distribution variations). I believe it's crucial to add basic Linux support, leaving the more specific discrimination (SSE support and whatnot) for the next version.

One reason to add basic Linux support is this: when building a docker container, pip install gevent (or similar) will take a lot of time, everytime, because every pip install actually behaves like pip install --no-cache-dir. This can easily become painful: if at the end of a docker build there's an error and you have to modify the Dockerfile, the next build will again need to recompile everything (as opposed to just re-download everything).

@ncoghlan
Copy link
Member

The "manylinux1" concept @njsmith recently posted about on distutils-sig seems like the most promising prospect for near term progress: https://mail.python.org/pipermail/distutils-sig/2016-January/027980.html

@repjak repjak mentioned this issue Feb 15, 2016
Closed
@piotr-dobrogost
Copy link

I know @ncoghlan was working on this with regard to identification of Linux distributions by means of lsb_realease and such. Nick, could you please link here relevant discussions that were taking place?

@ncoghlan
Copy link
Member

"working on" is a generous description - "kicking ideas around" was as far I got, although Nate Coraor took things further for use in https://galaxyproject.org/

The original incarnation of the idea was this proposal to use /etc/os-release: https://mail.python.org/pipermail/distutils-sig/2014-November/025297.html

Nate then set about turning that idea into reality: https://mail.python.org/pipermail/distutils-sig/2015-July/026616.html

@StephanErb
Copy link

FWIW there is also the manylinux proposal: https://code.activestate.com/lists/python-distutils-sig/27556/ and https://www.python.org/dev/peps/pep-0513/

@ncoghlan
Copy link
Member

Yes, we see the two proposals as complementary - manylinux1 for "one size fits most" wheels, and the more specific ones for when you want to build wheel files that are optimised for a specific distribution, but don't want them accidentally confusing matters for anyone using a different distribution.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
Wheel
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@piotr-dobrogost @StephanErb @ncoghlan @qwcode @soltanmm and others