570 lines
23 KiB
Plaintext
570 lines
23 KiB
Plaintext
PEP: 508
|
||
Title: Dependency specification for Python Software Packages
|
||
Version: $Revision$
|
||
Last-Modified: $Date$
|
||
Author: Robert Collins <rbtcollins@hp.com>
|
||
BDFL-Delegate: Donald Stufft <donald@stufft.io>
|
||
Discussions-To: distutils-sig@python.org
|
||
Status: Final
|
||
Type: Standards Track
|
||
Topic: Packaging
|
||
Content-Type: text/x-rst
|
||
Created: 11-Nov-2015
|
||
Post-History: 05-Nov-2015, 16-Nov-2015
|
||
Resolution: https://mail.python.org/pipermail/distutils-sig/2015-November/027868.html
|
||
|
||
|
||
Abstract
|
||
========
|
||
|
||
This PEP specifies the language used to describe dependencies for packages.
|
||
It draws a border at the edge of describing a single dependency - the
|
||
different sorts of dependencies and when they should be installed is a higher
|
||
level problem. The intent is to provide a building block for higher layer
|
||
specifications.
|
||
|
||
The job of a dependency is to enable tools like pip [#pip]_ to find the right
|
||
package to install. Sometimes this is very loose - just specifying a name, and
|
||
sometimes very specific - referring to a specific file to install. Sometimes
|
||
dependencies are only relevant in one platform, or only some versions are
|
||
acceptable, so the language permits describing all these cases.
|
||
|
||
The language defined is a compact line based format which is already in
|
||
widespread use in pip requirements files, though we do not specify the command
|
||
line option handling that those files permit. There is one caveat - the
|
||
URL reference form, specified in :pep:`440` is not actually
|
||
implemented in pip, but since :pep:`440` is accepted, we use that format rather
|
||
than pip's current native format.
|
||
|
||
Motivation
|
||
==========
|
||
|
||
Any specification in the Python packaging ecosystem that needs to consume
|
||
lists of dependencies needs to build on an approved PEP for such, but
|
||
:pep:`426` is mostly aspirational - and there are already existing
|
||
implementations of the dependency specification which we can instead adopt.
|
||
The existing implementations are battle proven and user friendly, so adopting
|
||
them is arguably much better than approving an aspirational, unconsumed, format.
|
||
|
||
Specification
|
||
=============
|
||
|
||
Examples
|
||
--------
|
||
|
||
All features of the language shown with a name based lookup::
|
||
|
||
requests [security,tests] >= 2.8.1, == 2.8.* ; python_version < "2.7"
|
||
|
||
A minimal URL based lookup::
|
||
|
||
pip @ https://github.com/pypa/pip/archive/1.3.1.zip#sha1=da9234ee9982d4bbb3c72346a6de940a148ea686
|
||
|
||
Concepts
|
||
--------
|
||
|
||
A dependency specification always specifies a distribution name. It may
|
||
include extras, which expand the dependencies of the named distribution to
|
||
enable optional features. The version installed can be controlled using
|
||
version limits, or giving the URL to a specific artifact to install. Finally
|
||
the dependency can be made conditional using environment markers.
|
||
|
||
Grammar
|
||
-------
|
||
|
||
We first cover the grammar briefly and then drill into the semantics of each
|
||
section later.
|
||
|
||
A distribution specification is written in ASCII text. We use a parsley
|
||
[#parsley]_ grammar to provide a precise grammar. It is expected that the
|
||
specification will be embedded into a larger system which offers framing such
|
||
as comments, multiple line support via continuations, or other such features.
|
||
|
||
The full grammar including annotations to build a useful parse tree is
|
||
included at the end of the PEP.
|
||
|
||
Versions may be specified according to the :pep:`440` rules. (Note:
|
||
URI is defined in :rfc:`std-66 <3986>`)::
|
||
|
||
version_cmp = wsp* '<' | '<=' | '!=' | '==' | '>=' | '>' | '~=' | '==='
|
||
version = wsp* ( letterOrDigit | '-' | '_' | '.' | '*' | '+' | '!' )+
|
||
version_one = version_cmp version wsp*
|
||
version_many = version_one (wsp* ',' version_one)*
|
||
versionspec = ( '(' version_many ')' ) | version_many
|
||
urlspec = '@' wsp* <URI_reference>
|
||
|
||
Environment markers allow making a specification only take effect in some
|
||
environments::
|
||
|
||
marker_op = version_cmp | (wsp* 'in') | (wsp* 'not' wsp+ 'in')
|
||
python_str_c = (wsp | letter | digit | '(' | ')' | '.' | '{' | '}' |
|
||
'-' | '_' | '*' | '#' | ':' | ';' | ',' | '/' | '?' |
|
||
'[' | ']' | '!' | '~' | '`' | '@' | '$' | '%' | '^' |
|
||
'&' | '=' | '+' | '|' | '<' | '>' )
|
||
dquote = '"'
|
||
squote = '\\''
|
||
python_str = (squote (python_str_c | dquote)* squote |
|
||
dquote (python_str_c | squote)* dquote)
|
||
env_var = ('python_version' | 'python_full_version' |
|
||
'os_name' | 'sys_platform' | 'platform_release' |
|
||
'platform_system' | 'platform_version' |
|
||
'platform_machine' | 'platform_python_implementation' |
|
||
'implementation_name' | 'implementation_version' |
|
||
'extra' # ONLY when defined by a containing layer
|
||
)
|
||
marker_var = wsp* (env_var | python_str)
|
||
marker_expr = marker_var marker_op marker_var
|
||
| wsp* '(' marker wsp* ')'
|
||
marker_and = marker_expr wsp* 'and' marker_expr
|
||
| marker_expr
|
||
marker_or = marker_and wsp* 'or' marker_and
|
||
| marker_and
|
||
marker = marker_or
|
||
quoted_marker = ';' wsp* marker
|
||
|
||
Optional components of a distribution may be specified using the extras
|
||
field::
|
||
|
||
identifier_end = letterOrDigit | (('-' | '_' | '.' )* letterOrDigit)
|
||
identifier = letterOrDigit identifier_end*
|
||
name = identifier
|
||
extras_list = identifier (wsp* ',' wsp* identifier)*
|
||
extras = '[' wsp* extras_list? wsp* ']'
|
||
|
||
Giving us a rule for name based requirements::
|
||
|
||
name_req = name wsp* extras? wsp* versionspec? wsp* quoted_marker?
|
||
|
||
And a rule for direct reference specifications::
|
||
|
||
url_req = name wsp* extras? wsp* urlspec wsp+ quoted_marker?
|
||
|
||
Leading to the unified rule that can specify a dependency.::
|
||
|
||
specification = wsp* ( url_req | name_req ) wsp*
|
||
|
||
Whitespace
|
||
----------
|
||
|
||
Non line-breaking whitespace is mostly optional with no semantic meaning. The
|
||
sole exception is detecting the end of a URL requirement.
|
||
|
||
Names
|
||
-----
|
||
|
||
Python distribution names are currently defined in :pep:`345`. Names
|
||
act as the primary identifier for distributions. They are present in all
|
||
dependency specifications, and are sufficient to be a specification on their
|
||
own. However, PyPI places strict restrictions on names - they must match a
|
||
case insensitive regex or they won't be accepted. Accordingly, in this PEP we
|
||
limit the acceptable values for identifiers to that regex. A full redefinition
|
||
of name may take place in a future metadata PEP. The regex (run with
|
||
re.IGNORECASE) is::
|
||
|
||
^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])$
|
||
|
||
Extras
|
||
------
|
||
|
||
An extra is an optional part of a distribution. Distributions can specify as
|
||
many extras as they wish, and each extra results in the declaration of
|
||
additional dependencies of the distribution **when** the extra is used in a
|
||
dependency specification. For instance::
|
||
|
||
requests[security]
|
||
|
||
Extras union in the dependencies they define with the dependencies of the
|
||
distribution they are attached to. The example above would result in requests
|
||
being installed, and requests own dependencies, and also any dependencies that
|
||
are listed in the "security" extra of requests.
|
||
|
||
If multiple extras are listed, all the dependencies are unioned together.
|
||
|
||
Versions
|
||
--------
|
||
|
||
See :pep:`440` for more detail on both version numbers and version
|
||
comparisons. Version specifications limit the versions of a distribution that
|
||
can be used. They only apply to distributions looked up by name, rather than
|
||
via a URL. Version comparison are also used in the markers feature. The
|
||
optional brackets around a version are present for compatibility with :pep:`345`
|
||
but should not be generated, only accepted.
|
||
|
||
Environment Markers
|
||
-------------------
|
||
|
||
Environment markers allow a dependency specification to provide a rule that
|
||
describes when the dependency should be used. For instance, consider a package
|
||
that needs argparse. In Python 2.7 argparse is always present. On older Python
|
||
versions it has to be installed as a dependency. This can be expressed as so::
|
||
|
||
argparse;python_version<"2.7"
|
||
|
||
A marker expression evaluates to either True or False. When it evaluates to
|
||
False, the dependency specification should be ignored.
|
||
|
||
The marker language is inspired by Python itself, chosen for the ability to
|
||
safely evaluate it without running arbitrary code that could become a security
|
||
vulnerability. Markers were first standardised in :pep:`345`. This PEP
|
||
fixes some issues that were observed in the design described in :pep:`426`.
|
||
|
||
Comparisons in marker expressions are typed by the comparison operator. The
|
||
<marker_op> operators that are not in <version_cmp> perform the same as they
|
||
do for strings in Python. The <version_cmp> operators use the :pep:`440`
|
||
version comparison rules when those are defined (that is when both
|
||
sides have a valid version specifier). If there is no defined :pep:`440`
|
||
behaviour and the operator exists in Python, then the operator falls back to
|
||
the Python behaviour. Otherwise an error should be raised. e.g. the following
|
||
will result in errors::
|
||
|
||
"dog" ~= "fred"
|
||
python_version ~= "surprise"
|
||
|
||
User supplied constants are always encoded as strings with either ``'`` or
|
||
``"`` quote marks. Note that backslash escapes are not defined, but existing
|
||
implementations do support them. They are not included in this
|
||
specification because they add complexity and there is no observable need for
|
||
them today. Similarly we do not define non-ASCII character support: all the
|
||
runtime variables we are referencing are expected to be ASCII-only.
|
||
|
||
The variables in the marker grammar such as "os_name" resolve to values looked
|
||
up in the Python runtime. With the exception of "extra" all values are defined
|
||
on all Python versions today - it is an error in the implementation of markers
|
||
if a value is not defined.
|
||
|
||
Unknown variables must raise an error rather than resulting in a comparison
|
||
that evaluates to True or False.
|
||
|
||
Variables whose value cannot be calculated on a given Python implementation
|
||
should evaluate to ``0`` for versions, and an empty string for all other
|
||
variables.
|
||
|
||
The "extra" variable is special. It is used by wheels to signal which
|
||
specifications apply to a given extra in the wheel ``METADATA`` file, but
|
||
since the ``METADATA`` file is based on a draft version of :pep:`426`, there is
|
||
no current specification for this. Regardless, outside of a context where this
|
||
special handling is taking place, the "extra" variable should result in an
|
||
error like all other unknown variables.
|
||
|
||
.. list-table::
|
||
:header-rows: 1
|
||
|
||
* - Marker
|
||
- Python equivalent
|
||
- Sample values
|
||
* - ``os_name``
|
||
- ``os.name``
|
||
- ``posix``, ``java``
|
||
* - ``sys_platform``
|
||
- ``sys.platform``
|
||
- ``linux``, ``linux2``, ``darwin``, ``java1.8.0_51`` (note that "linux"
|
||
is from Python3 and "linux2" from Python2)
|
||
* - ``platform_machine``
|
||
- ``platform.machine()``
|
||
- ``x86_64``
|
||
* - ``platform_python_implementation``
|
||
- ``platform.python_implementation()``
|
||
- ``CPython``, ``Jython``
|
||
* - ``platform_release``
|
||
- ``platform.release()``
|
||
- ``3.14.1-x86_64-linode39``, ``14.5.0``, ``1.8.0_51``
|
||
* - ``platform_system``
|
||
- ``platform.system()``
|
||
- ``Linux``, ``Windows``, ``Java``
|
||
* - ``platform_version``
|
||
- ``platform.version()``
|
||
- ``#1 SMP Fri Apr 25 13:07:35 EDT 2014``
|
||
``Java HotSpot(TM) 64-Bit Server VM, 25.51-b03, Oracle Corporation``
|
||
``Darwin Kernel Version 14.5.0: Wed Jul 29 02:18:53 PDT 2015; root:xnu-2782.40.9~2/RELEASE_X86_64``
|
||
* - ``python_version``
|
||
- ``'.'.join(platform.python_version_tuple()[:2])``
|
||
- ``3.4``, ``2.7``
|
||
* - ``python_full_version``
|
||
- ``platform.python_version()``
|
||
- ``3.4.0``, ``3.5.0b1``
|
||
* - ``implementation_name``
|
||
- ``sys.implementation.name``
|
||
- ``cpython``
|
||
* - ``implementation_version``
|
||
- see definition below
|
||
- ``3.4.0``, ``3.5.0b1``
|
||
* - ``extra``
|
||
- An error except when defined by the context interpreting the
|
||
specification.
|
||
- ``test``
|
||
|
||
The ``implementation_version`` marker variable is derived from
|
||
``sys.implementation.version``::
|
||
|
||
def format_full_version(info):
|
||
version = '{0.major}.{0.minor}.{0.micro}'.format(info)
|
||
kind = info.releaselevel
|
||
if kind != 'final':
|
||
version += kind[0] + str(info.serial)
|
||
return version
|
||
|
||
if hasattr(sys, 'implementation'):
|
||
implementation_version = format_full_version(sys.implementation.version)
|
||
else:
|
||
implementation_version = "0"
|
||
|
||
Backwards Compatibility
|
||
=======================
|
||
|
||
Most of this PEP is already widely deployed and thus offers no compatibility
|
||
concerns.
|
||
|
||
There are however a few points where the PEP differs from the deployed base.
|
||
|
||
Firstly, :pep:`440` direct references haven't actually been deployed in the wild,
|
||
but they were designed to be compatibly added, and there are no known
|
||
obstacles to adding them to pip or other tools that consume the existing
|
||
dependency metadata in distributions - particularly since they won't be
|
||
permitted to be present in PyPI uploaded distributions anyway.
|
||
|
||
Secondly, :pep:`426` markers which have had some reasonable deployment,
|
||
particularly in wheels and pip, will handle version comparisons with
|
||
``python_full_version`` "2.7.10" differently. Specifically in 426 "2.7.10" is
|
||
less than "2.7.9". This backward incompatibility is deliberate. We are also
|
||
defining new operators - "~=" and "===", and new variables -
|
||
``platform_release``, ``platform_system``, ``implementation_name``, and
|
||
``implementation_version`` which are not present in older marker
|
||
implementations. The variables will error on those implementations. Users of
|
||
both features will need to make a judgement as to when support has become
|
||
sufficiently widespread in the ecosystem that using them will not cause
|
||
compatibility issues.
|
||
|
||
Thirdly, :pep:`345` required brackets around version specifiers. In order to
|
||
accept :pep:`345` dependency specifications, brackets are accepted, but they
|
||
should not be generated.
|
||
|
||
Rationale
|
||
=========
|
||
|
||
In order to move forward with any new PEPs that depend on environment markers,
|
||
we needed a specification that included them in their modern form. This PEP
|
||
brings together all the currently unspecified components into a specified
|
||
form.
|
||
|
||
The requirement specifier was adopted from the EBNF in the setuptools
|
||
pkg_resources documentation, since we wish to avoid depending on a de facto, vs
|
||
PEP specified, standard.
|
||
|
||
Complete Grammar
|
||
================
|
||
|
||
The complete parsley grammar::
|
||
|
||
wsp = ' ' | '\t'
|
||
version_cmp = wsp* <'<=' | '<' | '!=' | '==' | '>=' | '>' | '~=' | '==='>
|
||
version = wsp* <( letterOrDigit | '-' | '_' | '.' | '*' | '+' | '!' )+>
|
||
version_one = version_cmp:op version:v wsp* -> (op, v)
|
||
version_many = version_one:v1 (wsp* ',' version_one)*:v2 -> [v1] + v2
|
||
versionspec = ('(' version_many:v ')' ->v) | version_many
|
||
urlspec = '@' wsp* <URI_reference>
|
||
marker_op = version_cmp | (wsp* 'in') | (wsp* 'not' wsp+ 'in')
|
||
python_str_c = (wsp | letter | digit | '(' | ')' | '.' | '{' | '}' |
|
||
'-' | '_' | '*' | '#' | ':' | ';' | ',' | '/' | '?' |
|
||
'[' | ']' | '!' | '~' | '`' | '@' | '$' | '%' | '^' |
|
||
'&' | '=' | '+' | '|' | '<' | '>' )
|
||
dquote = '"'
|
||
squote = '\\''
|
||
python_str = (squote <(python_str_c | dquote)*>:s squote |
|
||
dquote <(python_str_c | squote)*>:s dquote) -> s
|
||
env_var = ('python_version' | 'python_full_version' |
|
||
'os_name' | 'sys_platform' | 'platform_release' |
|
||
'platform_system' | 'platform_version' |
|
||
'platform_machine' | 'platform_python_implementation' |
|
||
'implementation_name' | 'implementation_version' |
|
||
'extra' # ONLY when defined by a containing layer
|
||
):varname -> lookup(varname)
|
||
marker_var = wsp* (env_var | python_str)
|
||
marker_expr = marker_var:l marker_op:o marker_var:r -> (o, l, r)
|
||
| wsp* '(' marker:m wsp* ')' -> m
|
||
marker_and = marker_expr:l wsp* 'and' marker_expr:r -> ('and', l, r)
|
||
| marker_expr:m -> m
|
||
marker_or = marker_and:l wsp* 'or' marker_and:r -> ('or', l, r)
|
||
| marker_and:m -> m
|
||
marker = marker_or
|
||
quoted_marker = ';' wsp* marker
|
||
identifier_end = letterOrDigit | (('-' | '_' | '.' )* letterOrDigit)
|
||
identifier = < letterOrDigit identifier_end* >
|
||
name = identifier
|
||
extras_list = identifier:i (wsp* ',' wsp* identifier)*:ids -> [i] + ids
|
||
extras = '[' wsp* extras_list?:e wsp* ']' -> e
|
||
name_req = (name:n wsp* extras?:e wsp* versionspec?:v wsp* quoted_marker?:m
|
||
-> (n, e or [], v or [], m))
|
||
url_req = (name:n wsp* extras?:e wsp* urlspec:v (wsp+ | end) quoted_marker?:m
|
||
-> (n, e or [], v, m))
|
||
specification = wsp* ( url_req | name_req ):s wsp* -> s
|
||
# The result is a tuple - name, list-of-extras,
|
||
# list-of-version-constraints-or-a-url, marker-ast or None
|
||
|
||
|
||
URI_reference = <URI | relative_ref>
|
||
URI = scheme ':' hier_part ('?' query )? ( '#' fragment)?
|
||
hier_part = ('//' authority path_abempty) | path_absolute | path_rootless | path_empty
|
||
absolute_URI = scheme ':' hier_part ( '?' query )?
|
||
relative_ref = relative_part ( '?' query )? ( '#' fragment )?
|
||
relative_part = '//' authority path_abempty | path_absolute | path_noscheme | path_empty
|
||
scheme = letter ( letter | digit | '+' | '-' | '.')*
|
||
authority = ( userinfo '@' )? host ( ':' port )?
|
||
userinfo = ( unreserved | pct_encoded | sub_delims | ':')*
|
||
host = IP_literal | IPv4address | reg_name
|
||
port = digit*
|
||
IP_literal = '[' ( IPv6address | IPvFuture) ']'
|
||
IPvFuture = 'v' hexdig+ '.' ( unreserved | sub_delims | ':')+
|
||
IPv6address = (
|
||
( h16 ':'){6} ls32
|
||
| '::' ( h16 ':'){5} ls32
|
||
| ( h16 )? '::' ( h16 ':'){4} ls32
|
||
| ( ( h16 ':')? h16 )? '::' ( h16 ':'){3} ls32
|
||
| ( ( h16 ':'){0,2} h16 )? '::' ( h16 ':'){2} ls32
|
||
| ( ( h16 ':'){0,3} h16 )? '::' h16 ':' ls32
|
||
| ( ( h16 ':'){0,4} h16 )? '::' ls32
|
||
| ( ( h16 ':'){0,5} h16 )? '::' h16
|
||
| ( ( h16 ':'){0,6} h16 )? '::' )
|
||
h16 = hexdig{1,4}
|
||
ls32 = ( h16 ':' h16) | IPv4address
|
||
IPv4address = dec_octet '.' dec_octet '.' dec_octet '.' dec_octet
|
||
nz = ~'0' digit
|
||
dec_octet = (
|
||
digit # 0-9
|
||
| nz digit # 10-99
|
||
| '1' digit{2} # 100-199
|
||
| '2' ('0' | '1' | '2' | '3' | '4') digit # 200-249
|
||
| '25' ('0' | '1' | '2' | '3' | '4' | '5') )# %250-255
|
||
reg_name = ( unreserved | pct_encoded | sub_delims)*
|
||
path = (
|
||
path_abempty # begins with '/' or is empty
|
||
| path_absolute # begins with '/' but not '//'
|
||
| path_noscheme # begins with a non-colon segment
|
||
| path_rootless # begins with a segment
|
||
| path_empty ) # zero characters
|
||
path_abempty = ( '/' segment)*
|
||
path_absolute = '/' ( segment_nz ( '/' segment)* )?
|
||
path_noscheme = segment_nz_nc ( '/' segment)*
|
||
path_rootless = segment_nz ( '/' segment)*
|
||
path_empty = pchar{0}
|
||
segment = pchar*
|
||
segment_nz = pchar+
|
||
segment_nz_nc = ( unreserved | pct_encoded | sub_delims | '@')+
|
||
# non-zero-length segment without any colon ':'
|
||
pchar = unreserved | pct_encoded | sub_delims | ':' | '@'
|
||
query = ( pchar | '/' | '?')*
|
||
fragment = ( pchar | '/' | '?')*
|
||
pct_encoded = '%' hexdig
|
||
unreserved = letter | digit | '-' | '.' | '_' | '~'
|
||
reserved = gen_delims | sub_delims
|
||
gen_delims = ':' | '/' | '?' | '#' | '(' | ')?' | '@'
|
||
sub_delims = '!' | '$' | '&' | '\\'' | '(' | ')' | '*' | '+' | ',' | ';' | '='
|
||
hexdig = digit | 'a' | 'A' | 'b' | 'B' | 'c' | 'C' | 'd' | 'D' | 'e' | 'E' | 'f' | 'F'
|
||
|
||
A test program - if the grammar is in a string ``grammar``::
|
||
|
||
import os
|
||
import sys
|
||
import platform
|
||
|
||
from parsley import makeGrammar
|
||
|
||
grammar = """
|
||
wsp ...
|
||
"""
|
||
tests = [
|
||
"A",
|
||
"A.B-C_D",
|
||
"aa",
|
||
"name",
|
||
"name<=1",
|
||
"name>=3",
|
||
"name>=3,<2",
|
||
"name@http://foo.com",
|
||
"name [fred,bar] @ http://foo.com ; python_version=='2.7'",
|
||
"name[quux, strange];python_version<'2.7' and platform_version=='2'",
|
||
"name; os_name=='a' or os_name=='b'",
|
||
# Should parse as (a and b) or c
|
||
"name; os_name=='a' and os_name=='b' or os_name=='c'",
|
||
# Overriding precedence -> a and (b or c)
|
||
"name; os_name=='a' and (os_name=='b' or os_name=='c')",
|
||
# should parse as a or (b and c)
|
||
"name; os_name=='a' or os_name=='b' and os_name=='c'",
|
||
# Overriding precedence -> (a or b) and c
|
||
"name; (os_name=='a' or os_name=='b') and os_name=='c'",
|
||
]
|
||
|
||
def format_full_version(info):
|
||
version = '{0.major}.{0.minor}.{0.micro}'.format(info)
|
||
kind = info.releaselevel
|
||
if kind != 'final':
|
||
version += kind[0] + str(info.serial)
|
||
return version
|
||
|
||
if hasattr(sys, 'implementation'):
|
||
implementation_version = format_full_version(sys.implementation.version)
|
||
implementation_name = sys.implementation.name
|
||
else:
|
||
implementation_version = '0'
|
||
implementation_name = ''
|
||
bindings = {
|
||
'implementation_name': implementation_name,
|
||
'implementation_version': implementation_version,
|
||
'os_name': os.name,
|
||
'platform_machine': platform.machine(),
|
||
'platform_python_implementation': platform.python_implementation(),
|
||
'platform_release': platform.release(),
|
||
'platform_system': platform.system(),
|
||
'platform_version': platform.version(),
|
||
'python_full_version': platform.python_version(),
|
||
'python_version': '.'.join(platform.python_version_tuple()[:2]),
|
||
'sys_platform': sys.platform,
|
||
}
|
||
|
||
compiled = makeGrammar(grammar, {'lookup': bindings.__getitem__})
|
||
for test in tests:
|
||
parsed = compiled(test).specification()
|
||
print("%s -> %s" % (test, parsed))
|
||
|
||
|
||
Summary of changes to PEP 508
|
||
=============================
|
||
|
||
The following changes were made to this PEP based on feedback after its initial
|
||
implementation:
|
||
|
||
- The definition of ``python_version`` was changed from
|
||
``platform.python_version()[:3]`` to
|
||
``'.'.join(platform.python_version_tuple()[:2])``, to accommodate potential
|
||
future versions of Python with 2-digit major and minor versions
|
||
(e.g. 3.10). [#future_versions]_
|
||
|
||
|
||
References
|
||
==========
|
||
|
||
.. [#pip] pip, the recommended installer for Python packages
|
||
(http://pip.readthedocs.org/en/stable/)
|
||
|
||
.. [#parsley] The parsley PEG library.
|
||
(https://pypi.python.org/pypi/parsley/)
|
||
|
||
.. [#future_versions] Future Python versions might be problematic with the
|
||
definition of Environment Marker Variable ``python_version``
|
||
(https://github.com/python/peps/issues/560)
|
||
|
||
Copyright
|
||
=========
|
||
|
||
This document has been placed in the public domain.
|
||
|
||
|
||
|
||
..
|
||
Local Variables:
|
||
mode: indented-text
|
||
indent-tabs-mode: nil
|
||
sentence-end-double-space: t
|
||
fill-column: 70
|
||
coding: utf-8
|
||
End:
|