updated after some feedback from distutils-SIG and MAL
This commit is contained in:
parent
07c651b6d2
commit
c8c5884bff
90
pep-0390.txt
90
pep-0390.txt
|
@ -62,6 +62,24 @@ fields. If an option that corresponds to a Metadata field is given to
|
||||||
``setup()``, it will override the value that was possibly present in
|
``setup()``, it will override the value that was possibly present in
|
||||||
``setup.cfg``.
|
``setup.cfg``.
|
||||||
|
|
||||||
|
Notice that ``setup.py`` is still used and can be required to define some
|
||||||
|
options that are not part of the Metadata fields. For instance, the
|
||||||
|
``sdist`` command can use options like ``packages`` or ``scripts``.
|
||||||
|
|
||||||
|
|
||||||
|
Multi-lines values
|
||||||
|
==================
|
||||||
|
|
||||||
|
Some Metadata fields can have multiple values. To keep ``setup.cfg`` compatible
|
||||||
|
with ``ConfigParser`` and the RFC 822 ``LONG HEADER FIELDS`` (see section 3.1.1),
|
||||||
|
these are expressed with ``,``-separated values::
|
||||||
|
|
||||||
|
requires = pywin32, bar > 1.0, foo
|
||||||
|
|
||||||
|
When this variable is read, the values are parsed and transformed into a list:
|
||||||
|
``['pywin32', 'bar > 1.0', 'foo']``.
|
||||||
|
|
||||||
|
|
||||||
Context-dependant sections
|
Context-dependant sections
|
||||||
==========================
|
==========================
|
||||||
|
|
||||||
|
@ -75,8 +93,8 @@ environment. Here's some examples::
|
||||||
version = 0.6.4
|
version = 0.6.4
|
||||||
|
|
||||||
[metadata:sys_platform == 'win32']
|
[metadata:sys_platform == 'win32']
|
||||||
requires = pywin32
|
requires = pywin32, bar > 1.0
|
||||||
requires = bar > 1.0
|
obsoletes = pywin31
|
||||||
|
|
||||||
[metadata:os_machine == 'i386']
|
[metadata:os_machine == 'i386']
|
||||||
requires = foo
|
requires = foo
|
||||||
|
@ -107,11 +125,14 @@ where ``EXPR`` belongs to any of those:
|
||||||
- python_version = '%s.%s' % (sys.version_info[0], sys.version_info[1])
|
- python_version = '%s.%s' % (sys.version_info[0], sys.version_info[1])
|
||||||
- os_name = os.name
|
- os_name = os.name
|
||||||
- sys_platform = sys.platform
|
- sys_platform = sys.platform
|
||||||
- os_version = os.uname()[3]
|
- platform_version = platform.version()
|
||||||
- os_machine = os.uname()[4]
|
- platform_machine = platform.machine()
|
||||||
- a free string, like ``2.4``, or ``win32``
|
- a free string, like ``2.4``, or ``win32``
|
||||||
|
|
||||||
Distutils will provide a function that is able to read the metadata
|
Notice that ``in`` is restricted to strings, meaning that it is not possible
|
||||||
|
to use other sequences like tuples or lists on the left side.
|
||||||
|
|
||||||
|
Distutils will provide a function that is able to generate the metadata
|
||||||
of a distribution, given a ``setup.cfg`` file, for the execution environment::
|
of a distribution, given a ``setup.cfg`` file, for the execution environment::
|
||||||
|
|
||||||
>>> from distutils.util import local_metadata
|
>>> from distutils.util import local_metadata
|
||||||
|
@ -121,11 +142,66 @@ of a distribution, given a ``setup.cfg`` file, for the execution environment::
|
||||||
This means that a vanilla Python will be able to read the metadata of a
|
This means that a vanilla Python will be able to read the metadata of a
|
||||||
package without running any third party code.
|
package without running any third party code.
|
||||||
|
|
||||||
|
Notice that this feature is not restricted to the ``metadata`` namespace.
|
||||||
|
Consequently, any other section can be extended with such context-dependant
|
||||||
|
sections.
|
||||||
|
|
||||||
|
Impact on PKG-INFO generation and PEP 314
|
||||||
|
=========================================
|
||||||
|
|
||||||
|
When ``PKG-INFO`` is generated by Distutils, every field that relies on a
|
||||||
|
condition will have that condition written at the end of the line, after a `;`
|
||||||
|
separator::
|
||||||
|
|
||||||
|
Metadata-Version: 1.2
|
||||||
|
Name: distribute
|
||||||
|
Version: 0.6.4
|
||||||
|
...
|
||||||
|
Requires: pywin32, bar > 1.0; sys_platform == 'win32'
|
||||||
|
Requires: foo; os_machine == 'i386'
|
||||||
|
Requires: bar; python_version == '2.4' or python_version == '2.5'
|
||||||
|
Requires: baz; 'linux' in sys_platform
|
||||||
|
Obsoletes = pywin31; sys_platform == 'win32'
|
||||||
|
...
|
||||||
|
Classifier: Development Status :: 5 - Production/Stable
|
||||||
|
Classifier: Intended Audience :: Developers
|
||||||
|
Classifier: License :: OSI Approved :: Python Software Foundation License
|
||||||
|
|
||||||
|
Notice that this file can be opened with the ``DistributionMetadata`` class.
|
||||||
|
This class will be able to use the micro-language using the execution
|
||||||
|
environment.
|
||||||
|
|
||||||
|
Let's run in on a ``Python 2.5 i386 Linux``::
|
||||||
|
|
||||||
|
>>> from distutils.dist import DistributionMetadata
|
||||||
|
>>> metadata = DistributionMetadata('PKG_INFO')
|
||||||
|
>>> metadata.get_requires()
|
||||||
|
['foo', 'bar', 'baz']
|
||||||
|
|
||||||
|
The execution environment can be overriden in case we want to get the meyadata
|
||||||
|
for another environment::
|
||||||
|
|
||||||
|
>>> env = {'python_version': '2.4',
|
||||||
|
... 'os_name': 'nt',
|
||||||
|
... 'sys_platform': 'win32',
|
||||||
|
... 'platform_version': 'MVCC++ 6.0'
|
||||||
|
... 'platform_machine': 'i386'}
|
||||||
|
...
|
||||||
|
>>> metadata = DistributionMetadata('PKG_INFO', environment=env)
|
||||||
|
>>> metadata.get_requires()
|
||||||
|
['bar > 1.0', 'foo', 'bar']
|
||||||
|
|
||||||
|
PEP 314 is changed accordingly, meaning that each field will be able to
|
||||||
|
have that extra condition marker.
|
||||||
|
|
||||||
Compatiblity
|
Compatiblity
|
||||||
============
|
============
|
||||||
|
|
||||||
This change is fully backward compatible since it just adds a section in the
|
This change is is based on a new metadata ``1.2`` format meaning that
|
||||||
``ConfigParser``-compatible ``setup.cfg`` file.
|
Distutils will be able to distinguish old PKG-INFO files from new ones.
|
||||||
|
|
||||||
|
The ``setup.cfg`` file change will stay ``ConfigParser``-compatible and
|
||||||
|
will not break existing ``setup.cfg`` files.
|
||||||
|
|
||||||
Limitations
|
Limitations
|
||||||
===========
|
===========
|
||||||
|
|
Loading…
Reference in New Issue