2009-10-10 19:56:30 -04:00
|
|
|
|
PEP: 390
|
|
|
|
|
Title: Static metadata for Distutils
|
2010-03-02 21:55:24 -05:00
|
|
|
|
Version: $Revision$
|
|
|
|
|
Last-Modified: $Date$
|
2009-10-10 19:56:30 -04:00
|
|
|
|
Author: Tarek Ziadé <tarek@ziade.org>
|
2013-05-18 04:08:49 -04:00
|
|
|
|
BDFL-Delegate: Nick Coghlan
|
|
|
|
|
Discussions-To: <distutils-sig@python.org>
|
|
|
|
|
Status: Rejected
|
2009-10-10 19:56:30 -04:00
|
|
|
|
Type: Standards Track
|
|
|
|
|
Content-Type: text/x-rst
|
|
|
|
|
Created: 10-October-2009
|
|
|
|
|
Python-Version: 2.7 and 3.2
|
|
|
|
|
Post-History:
|
2013-05-18 04:08:49 -04:00
|
|
|
|
Resolution: http://mail.python.org/pipermail/distutils-sig/2013-April/020597.html
|
2009-10-10 19:56:30 -04:00
|
|
|
|
|
|
|
|
|
Abstract
|
|
|
|
|
========
|
|
|
|
|
|
|
|
|
|
This PEP describes a new section and a new format for the ``setup.cfg`` file,
|
|
|
|
|
that allows describing the Metadata of a package without using ``setup.py``.
|
|
|
|
|
|
2013-05-18 04:08:49 -04:00
|
|
|
|
|
|
|
|
|
Rejection Notice
|
|
|
|
|
================
|
|
|
|
|
|
|
|
|
|
As distutils2 is no longer going to be incorporated into the standard
|
|
|
|
|
library, this PEP was rejected by Nick Coghlan in late April, 2013.
|
|
|
|
|
|
|
|
|
|
A replacement PEP based on PEP 426 (metadata 2.0) will be created that
|
|
|
|
|
defines the minimum amount of information needed to generate an sdist
|
|
|
|
|
archive given a source tarball or VCS checkout.
|
|
|
|
|
|
|
|
|
|
|
2009-10-10 19:56:30 -04:00
|
|
|
|
Rationale
|
|
|
|
|
=========
|
|
|
|
|
|
|
|
|
|
Today, if you want to list all the Metadata of a distribution (see PEP 314)
|
|
|
|
|
that is not installed, you need to use the ``setup.py`` command line interface.
|
|
|
|
|
|
|
|
|
|
So, basically, you download it, and run::
|
|
|
|
|
|
|
|
|
|
$ python setup.py --name
|
|
|
|
|
Distribute
|
|
|
|
|
|
|
|
|
|
$ python setup.py --version
|
|
|
|
|
0.6.4
|
|
|
|
|
|
|
|
|
|
Where ``name`` and ``version`` are metadata fields. This is working fine but
|
2009-10-12 10:59:50 -04:00
|
|
|
|
as soon as the developers add more code in ``setup.py``, this feature might
|
2009-10-10 19:56:30 -04:00
|
|
|
|
break or in worst cases might do unwanted things on the target system.
|
|
|
|
|
|
|
|
|
|
Moreover, when an OS packager wants to get the metadata of a distribution
|
|
|
|
|
he is re-packaging, he might encounter some problems to understand
|
|
|
|
|
the ``setup.py`` file he's working with.
|
|
|
|
|
|
|
|
|
|
So the rationale of this PEP is to provide a way to declare the metadata
|
|
|
|
|
in a static configuration file alongside ``setup.py`` that doesn't require
|
|
|
|
|
any third party code to run.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Adding a ``metadata`` section in ``setup.cfg``
|
|
|
|
|
==============================================
|
|
|
|
|
|
2009-10-12 10:59:50 -04:00
|
|
|
|
The first thing we want to introduce is a ``[metadata]`` section, in the
|
2009-10-10 19:56:30 -04:00
|
|
|
|
``setup.cfg`` file, that may contain any field from the Metadata::
|
|
|
|
|
|
|
|
|
|
[metadata]
|
|
|
|
|
name = Distribute
|
|
|
|
|
version = 0.6.4
|
|
|
|
|
|
|
|
|
|
The ``setup.cfg`` file is used to avoid adding yet another configuration
|
|
|
|
|
file to work with in Distutils.
|
|
|
|
|
|
|
|
|
|
This file is already read by Distutils when a command is executed, and
|
|
|
|
|
if the ``metadata`` section is found, it will be used to fill the metadata
|
|
|
|
|
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.cfg``.
|
|
|
|
|
|
2009-10-12 10:59:50 -04:00
|
|
|
|
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']``.
|
|
|
|
|
|
|
|
|
|
|
2009-10-10 19:56:30 -04:00
|
|
|
|
Context-dependant sections
|
|
|
|
|
==========================
|
|
|
|
|
|
|
|
|
|
The ``metadata`` section will also be able to use context-dependant sections.
|
|
|
|
|
|
|
|
|
|
A context-dependant section is a section with a condition about the execution
|
|
|
|
|
environment. Here's some examples::
|
|
|
|
|
|
|
|
|
|
[metadata]
|
|
|
|
|
name = Distribute
|
|
|
|
|
version = 0.6.4
|
|
|
|
|
|
|
|
|
|
[metadata:sys_platform == 'win32']
|
2009-10-12 10:59:50 -04:00
|
|
|
|
requires = pywin32, bar > 1.0
|
|
|
|
|
obsoletes = pywin31
|
2009-10-10 19:56:30 -04:00
|
|
|
|
|
|
|
|
|
[metadata:os_machine == 'i386']
|
2009-10-10 20:00:42 -04:00
|
|
|
|
requires = foo
|
2009-10-10 19:56:30 -04:00
|
|
|
|
|
|
|
|
|
[metadata:python_version == '2.4' or python_version == '2.5']
|
2009-10-10 20:00:42 -04:00
|
|
|
|
requires = bar
|
2009-10-10 19:56:30 -04:00
|
|
|
|
|
|
|
|
|
[metadata:'linux' in sys_platform]
|
2009-10-10 20:00:42 -04:00
|
|
|
|
requires = baz
|
2009-10-10 19:56:30 -04:00
|
|
|
|
|
|
|
|
|
Every ``[metadata:condition]`` section will be used only if the condition
|
|
|
|
|
is met when the file is read. The background motivation for these
|
|
|
|
|
context-dependant sections is to be able to define requirements that varies
|
2009-10-12 10:59:50 -04:00
|
|
|
|
depending on the platform the distribution might be installed on.
|
2009-10-10 19:56:30 -04:00
|
|
|
|
(see PEP 314).
|
|
|
|
|
|
|
|
|
|
The micro-language behind this is the simplest possible: it compares only
|
2009-10-12 10:59:50 -04:00
|
|
|
|
strings, with the ``==`` and ``in`` operators (and their opposites), and
|
|
|
|
|
with the ability to combine expressions. It makes it also easy to understand
|
2009-10-10 19:56:30 -04:00
|
|
|
|
to non-pythoneers.
|
|
|
|
|
|
|
|
|
|
The pseudo-grammar is ::
|
|
|
|
|
|
|
|
|
|
EXPR [in|==|!=|not in] EXPR [or|and] ...
|
|
|
|
|
|
|
|
|
|
where ``EXPR`` belongs to any of those:
|
|
|
|
|
|
|
|
|
|
- python_version = '%s.%s' % (sys.version_info[0], sys.version_info[1])
|
|
|
|
|
- os_name = os.name
|
|
|
|
|
- sys_platform = sys.platform
|
2009-10-12 10:59:50 -04:00
|
|
|
|
- platform_version = platform.version()
|
|
|
|
|
- platform_machine = platform.machine()
|
2009-10-10 19:56:30 -04:00
|
|
|
|
- a free string, like ``2.4``, or ``win32``
|
|
|
|
|
|
2009-10-12 10:59:50 -04:00
|
|
|
|
Notice that ``in`` is restricted to strings, meaning that it is not possible
|
2009-10-12 13:24:09 -04:00
|
|
|
|
to use other sequences like tuples or lists on the right side.
|
2009-10-12 10:59:50 -04:00
|
|
|
|
|
|
|
|
|
Distutils will provide a function that is able to generate the metadata
|
2009-10-10 19:56:30 -04:00
|
|
|
|
of a distribution, given a ``setup.cfg`` file, for the execution environment::
|
|
|
|
|
|
|
|
|
|
>>> from distutils.util import local_metadata
|
|
|
|
|
>>> local_metadata('setup.cfg')
|
|
|
|
|
<DistributionMetadata instance>
|
|
|
|
|
|
|
|
|
|
This means that a vanilla Python will be able to read the metadata of a
|
|
|
|
|
package without running any third party code.
|
|
|
|
|
|
2009-10-12 10:59:50 -04:00
|
|
|
|
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']
|
|
|
|
|
|
2016-07-11 11:14:08 -04:00
|
|
|
|
The execution environment can be overridden in case we want to get the metadata
|
2009-10-12 10:59:50 -04:00
|
|
|
|
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.
|
|
|
|
|
|
2016-07-11 11:14:08 -04:00
|
|
|
|
Compatibility
|
|
|
|
|
=============
|
2009-10-10 19:56:30 -04:00
|
|
|
|
|
2016-05-03 05:03:16 -04:00
|
|
|
|
This change is based on a new metadata ``1.2`` format meaning that
|
2009-10-12 10:59:50 -04:00
|
|
|
|
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.
|
2009-10-10 19:56:30 -04:00
|
|
|
|
|
|
|
|
|
Limitations
|
|
|
|
|
===========
|
|
|
|
|
|
|
|
|
|
We are not providing ``<`` and ``>`` operators at this time, and
|
|
|
|
|
``python_version`` is a regular string. This implies using ``or`` operators
|
|
|
|
|
when a section needs to be restricted to a couple of Python versions.
|
|
|
|
|
Although, if PEP 386 is accepted, ``python_version`` could be changed
|
2009-10-12 10:59:50 -04:00
|
|
|
|
internally into something comparable with strings, and
|
2009-10-10 19:56:30 -04:00
|
|
|
|
``<`` and ``>`` operators introduced.
|
|
|
|
|
|
|
|
|
|
Last, if a distribution is unable to set all metadata fields in ``setup.cfg``,
|
|
|
|
|
that's fine, the fields will be set to ``UNKNOWN`` when ``local_metadata`` is
|
2009-10-12 10:59:50 -04:00
|
|
|
|
called. Getting ``UNKNOWN`` values will mean that it might be necessary to
|
2009-10-10 19:56:30 -04:00
|
|
|
|
run the ``setup.py`` command line interface to get the whole set of metadata.
|
|
|
|
|
|
2009-10-11 18:46:05 -04:00
|
|
|
|
Acknowledgments
|
|
|
|
|
===============
|
2009-10-10 19:56:30 -04:00
|
|
|
|
|
|
|
|
|
The Distutils-SIG.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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:
|