360 lines
11 KiB
Plaintext
360 lines
11 KiB
Plaintext
PEP: 314
|
||
Title: Metadata for Python Software Packages v1.1
|
||
Version: $Revision$
|
||
Last-Modified: $Date$
|
||
Author: A.M. Kuchling <amk@amk.ca>
|
||
Status: Draft
|
||
Type: Standards Track
|
||
Content-type: text/plain
|
||
Created: 12-Apr-2003
|
||
Python-Version: 2.3
|
||
Post-History: 29-Apr-2003
|
||
Replaces: 243
|
||
|
||
Introduction
|
||
|
||
This PEP describes a mechanism for adding metadata to Python
|
||
packages. It includes specifics of the field names, and their
|
||
semantics and usage.
|
||
|
||
This document specifies version 1.1 of the metadata format.
|
||
Version 1.0 is specified in PEP 241.
|
||
|
||
|
||
Including Metadata in Packages
|
||
|
||
The Distutils 'sdist' command will extract the metadata fields
|
||
from the arguments and write them to a file in the generated
|
||
zipfile or tarball. This file will be named PKG-INFO and will be
|
||
placed in the top directory of the source distribution (where the
|
||
README, INSTALL, and other files usually go).
|
||
|
||
Developers may not provide their own PKG-INFO file. The "sdist"
|
||
command will, if it detects an existing PKG-INFO file, terminate
|
||
with an appropriate error message. This should prevent confusion
|
||
caused by the PKG-INFO and setup.py files being out of sync.
|
||
|
||
The PKG-INFO file format is a single set of RFC-822 headers
|
||
parseable by the rfc822.py module. The field names listed in the
|
||
following section are used as the header names. There's no
|
||
extension mechanism in this simple format.
|
||
|
||
|
||
Fields
|
||
|
||
This section specifies the names and semantics of each of the
|
||
supported metadata fields.
|
||
|
||
Fields marked with "(Multiple use)" may be specified multiple
|
||
times in a single PKG-INFO file. Other fields may only occur
|
||
once in a PKG-INFO file. Fields marked with "(optional)" are
|
||
not required to appear in a valid PKG-INFO file, all other
|
||
fields must be present.
|
||
|
||
Metadata-Version
|
||
|
||
Version of the file format; currently "1.0" and "1.1" are the
|
||
only legal values here.
|
||
|
||
Example:
|
||
|
||
Metadata-Version: 1.1
|
||
|
||
Name
|
||
|
||
The name of the package.
|
||
|
||
Example:
|
||
|
||
Name: BeagleVote
|
||
|
||
Version
|
||
|
||
A string containing the package's version number. This
|
||
field should be parseable by one of the Version classes
|
||
(StrictVersion or LooseVersion) in the distutils.version
|
||
module.
|
||
|
||
Example:
|
||
|
||
Version: 1.0a2
|
||
|
||
Platform (multiple use)
|
||
|
||
A comma-separated list of platform specifications, summarizing
|
||
the operating systems supported by the package. The major
|
||
supported platforms are listed below, but this list is
|
||
necessarily incomplete.
|
||
|
||
POSIX, MacOS, Windows, BeOS, PalmOS.
|
||
|
||
Example:
|
||
|
||
Platform: POSIX, Windows
|
||
|
||
Supported-Platform
|
||
|
||
Binary distributions containing a PKG-INFO file will use the
|
||
Supported-Platform field in their metadata to specify the OS and
|
||
CPU for which the binary package was compiled. The semantics of
|
||
the Supported-Platform field are not specified in this PEP.
|
||
|
||
Example:
|
||
|
||
Supported-Platform: RedHat 7.2
|
||
Supported-Platform: i386-win32-2791
|
||
|
||
Summary
|
||
|
||
A one-line summary of what the package does.
|
||
|
||
Example:
|
||
|
||
Summary: A module for collecting votes from beagles.
|
||
|
||
Description (optional)
|
||
|
||
A longer description of the package that can run to several
|
||
paragraphs. (Software that deals with metadata should not
|
||
assume any maximum size for this field, though one hopes that
|
||
people won't include their instruction manual as the
|
||
description.)
|
||
|
||
Example:
|
||
|
||
Description: This module collects votes from beagles
|
||
in order to determine their electoral wishes.
|
||
Do NOT try to use this module with basset hounds;
|
||
it makes them grumpy.
|
||
|
||
Keywords (optional)
|
||
|
||
A list of additional keywords to be used to assist searching
|
||
for the package in a larger catalog.
|
||
|
||
Example:
|
||
|
||
Keywords: dog puppy voting election
|
||
|
||
Home-page (optional)
|
||
|
||
A string containing the URL for the package's home page.
|
||
|
||
Example:
|
||
|
||
Home-page: http://www.example.com/~cschultz/bvote/
|
||
|
||
Download-URL
|
||
|
||
A string containing the URL from which this version of the package
|
||
can be downloaded. (This means that the URL can't be something like
|
||
".../package-latest.tgz", but instead must be "../package-0.45.tgz".)
|
||
|
||
Author (optional)
|
||
|
||
A string containing the author's name at a minimum; additional
|
||
contact information may be provided.
|
||
|
||
Example:
|
||
|
||
Author: C. Schultz, Universal Features Syndicate,
|
||
Los Angeles, CA <cschultz@peanuts.example.com>
|
||
|
||
Author-email
|
||
|
||
A string containing the author's e-mail address. It can contain
|
||
a name and e-mail address in the legal forms for a RFC-822
|
||
'From:' header. It's not optional because cataloging systems
|
||
can use the e-mail portion of this field as a unique key
|
||
representing the author. A catalog might provide authors the
|
||
ability to store their GPG key, personal home page, and other
|
||
additional metadata *about the author*, and optionally the
|
||
ability to associate several e-mail addresses with the same
|
||
person. Author-related metadata fields are not covered by this
|
||
PEP.
|
||
|
||
Example:
|
||
|
||
Author-email: "C. Schultz" <cschultz@example.com>
|
||
|
||
License
|
||
|
||
A string selected from a short list of choices, specifying the
|
||
license covering the package. Some licenses result in the
|
||
software being freely redistributable, so packagers and
|
||
resellers can automatically know that they're free to
|
||
redistribute the software. Other licenses will require
|
||
a careful reading by a human to determine how the software can be
|
||
repackaged and resold.
|
||
|
||
The choices are:
|
||
|
||
Artistic, BSD, DFSG, GNU GPL, GNU LGPL, "MIT",
|
||
Mozilla PL, "public domain", Python, Qt PL, Zope PL, unknown,
|
||
nocommercial, nosell, nosource, shareware, other
|
||
|
||
Definitions of some of the licenses are:
|
||
|
||
DFSG The license conforms to the Debian Free Software
|
||
Guidelines, but does not use one of the other
|
||
DFSG conforming licenses listed here.
|
||
More information is available at:
|
||
http://www.debian.org/social_contract#guidelines
|
||
|
||
Python Python 1.6 or higher license. Version 1.5.2 and
|
||
earlier are under the MIT license.
|
||
|
||
public domain Software is public domain, not copyrighted.
|
||
unknown Status is not known
|
||
nocommercial Free private use but commercial use not permitted
|
||
nosell Free use but distribution for profit by arrangement
|
||
nosource Freely distributable but no source code
|
||
shareware Payment is requested if software is used
|
||
other General category for other non-DFSG licenses
|
||
|
||
Some of these licenses can be interpreted to mean the software is
|
||
freely redistributable. The list of redistributable licenses is:
|
||
|
||
Artistic, BSD, DFSG, GNU GPL, GNU LGPL, "MIT",
|
||
Mozilla PL, "public domain", Python, Qt PL, Zope PL,
|
||
nosource, shareware
|
||
|
||
Note that being redistributable does not mean a package
|
||
qualifies as free software, 'nosource' and 'shareware' being
|
||
examples.
|
||
|
||
Example:
|
||
|
||
License: MIT
|
||
|
||
Classifier (multiple use)
|
||
|
||
Each entry is a string giving a single classification value
|
||
for the package. Classifiers are described in PEP 301 [1].
|
||
|
||
Examples:
|
||
|
||
Classifier: Development Status :: 4 - Beta
|
||
Classifier: Environment :: Console (Text Based)
|
||
|
||
|
||
Requires (multiple use)
|
||
|
||
Each entry contains a string describing some other component or
|
||
module required by this package.
|
||
|
||
The format of a requirement string is simple: an arbitrary
|
||
sequence of characters, optionally followed by a version
|
||
declaration within parentheses. Leading and trailing whitespace
|
||
are ignored, and whitespace within the string is normalized to a
|
||
single space.
|
||
|
||
A version declaration is a series of conditional operators and
|
||
version numbers, separated by commas. Conditional operators
|
||
must be one of "<", ">", "<=", ">=", "==", and "!=". Version
|
||
numbers must be in the format accepted by the
|
||
distutils.version.StrictVersion class: two or three
|
||
dot-separated numeric components, with an optional "pre-release"
|
||
tag on the end consisting of the letter 'a' or 'b' followed by a
|
||
number. Example version numbers are "1.0", "2.3a2", "1.3.99",
|
||
|
||
Any number of conditional operators can be specified, e.g.
|
||
the string ">1.0, !=1.3.4, <2.0" is a legal version declaration.
|
||
|
||
All of the following are possible requirement strings: "rfc822",
|
||
"zlib (>=1.1.4)", "XML parser".
|
||
|
||
There's no canonical list of what strings should be used; the
|
||
Python community is left to choose its own standards.
|
||
|
||
Example:
|
||
|
||
Requires: re
|
||
Requires: sys
|
||
Requires: zlib
|
||
Requires: pyexpat (>1.0)
|
||
Requires: DB-API 2.0 module
|
||
|
||
Provides (multiple use)
|
||
|
||
Each entry contains a string describing a component or
|
||
module that will be provided by this package once it is
|
||
installed. These strings should match the ones used in
|
||
Requirements fields. Version declarations cannot be supplied;
|
||
instead the package's version number will be used.
|
||
|
||
Example:
|
||
|
||
Provides: xml
|
||
Provides: xml.utils
|
||
Provides: xml.utils.iso8601
|
||
Provides: xml.dom
|
||
|
||
Obsoletes (multiple use)
|
||
|
||
Each entry contains a string describing a component or module
|
||
that this package renders obsolete, meaning that the two packages
|
||
should not be installed at the same time. Version declarations
|
||
can be supplied.
|
||
|
||
The most common use of this field will be in case a package name
|
||
changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0.
|
||
When you install Torqued Python, the Gorgon package should be
|
||
removed.
|
||
|
||
Example:
|
||
|
||
Obsoletes: Gorgon
|
||
|
||
Conflicts (multiple use)
|
||
|
||
Each entry contains a string describing a component or module
|
||
that conflicts with this package, meaning that the two packages
|
||
should not be installed at the same time. Version declarations
|
||
can be supplied.
|
||
|
||
Conflict resolution probably isn't very important for Python
|
||
programs, because few extensions will cause problems for other
|
||
extensions, unless they happen to be using the same package
|
||
name. This field name is being defined here for future use.
|
||
|
||
Conflicts: Gorgon
|
||
|
||
|
||
Summary of Differences From PEP 241
|
||
|
||
* Metadata-Version is now 1.1.
|
||
|
||
* Added the Classifiers field from PEP 301.
|
||
|
||
* Added fields: Download-URL, Requires, Provides, Obsoletes, Conflicts.
|
||
|
||
|
||
Open issues
|
||
|
||
With the addition of the 'Classifiers' field, should the Platform
|
||
and License fields be removed?
|
||
|
||
|
||
Acknowledgements
|
||
|
||
None yet.
|
||
|
||
|
||
References
|
||
|
||
[1] PEP 301
|
||
http://www.python.org/peps/pep-0301.html
|
||
|
||
|
||
Copyright
|
||
|
||
This document has been placed in the public domain.
|
||
|
||
|
||
|
||
Local Variables:
|
||
mode: indented-text
|
||
indent-tabs-mode: nil
|
||
End:
|