iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 425 (tags) - mention wheel filename convention

This commit is contained in:
Daniel Holth 2012-10-18 23:01:56 -04:00
parent 81da2e17a9
commit c70a54e10d
1 changed files with 34 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
pep-0425.txt
View File

@ -64,6 +64,14 @@ platform tag
For example, the tag py27-none-any indicates compatible with Python 2.7
(any Python 2.7 implementation) with no abi requirement, on any platform.
Use
===
The `wheel` built package format includes these tags in its filenames,
of the form ``{distribution}-{version}(-{build tag})?-{python tag}-{abi
tag}-{platform tag}.whl``. Other package formats may have their own
conventions.
Details
=======
@ -103,8 +111,7 @@ extension modules. For implementation-specific ABIs, the implementation
is abbreviated in the same way as the Python Tag, e.g. `cp33d` would be
the CPython 3.3 ABI with debugging.
The CPython stable ABI is `abi3` as in the shared library suffix, and
is available starting with Python 3.2.
The CPython stable ABI is `abi3` as in the shared library suffix.
Implementations with a very unstable ABI may use the first 6 bytes (as
8 base64-encoded characters) of the SHA-256 hash of ther source code
@ -135,19 +142,30 @@ For example, an installer running under CPython 3.3 on a linux_x86_64
system might support::
1. cp33-cp33m-linux_x86_64
2. cp33-none-linux_x86_64
3. cp3-abi3-linux_x86_64
2. cp33-abi3-linux_x86_64
3. cp33-none-linux_x86_64
4. cp33-none-any
5. cp3-none-any
6. py33-none-any
7. py3-none-any
6. cp32-none-any
7. cp31-none-any
8. cp30-none-any
9. py33-none-any
10. py3-none-any
11. py32-none-any
12. py31-none-any
13. py30-none-any
A user could instruct their installer to fall back to building from an
sdist more or less often by configuring this list of tags.
The list is in order from most-preferred (a distribution with a
compiled extension module, built for the current version of Python)
to least-preferred (a pure-Python distribution built with an older
version of Python). A user could instruct their installer to fall back
to building from an sdist more or less often by configuring this list of
tags; for example, a user could include only the `*-none-any` tags to only
download built packages that advertise themselves as being pure Python.
Rarely there will be more than one supported built distribution for a
particular version of a package. For example, a packager could release
a package tagged `cp3-abi3-linux_x86_64` that contains an optional C
a package tagged `cp33-abi3-linux_x86_64` that contains an optional C
extension and the same distribution tagged `py3-none-any` that does not.
The index of the tag in the supported tags list breaks the tie, and the
package with the C extension is installed in preference to the package
@ -176,6 +194,13 @@ by no Python implementation e.g. "cp33-cp31u-win64", so use it sparingly.
FAQ
===
What tags are used by default?
Tools should use the most-preferred architecture dependent tag
e.g. `cp33-cp33m-win32` or the most-preferred pure python tag
e.g. `py33-none-any` by default. If the packager overrides the
default it indicates that they intended to provide cross-Python
compatibility.
Can I have a tag `py32+` to indicate a minimum Python minor release?
No. Inspect the Trove classifiers to determine this level of
cross-release compatibility. Similar to the announcements "beaglevote