PEP 426/440 update

This commit is contained in:
Nick Coghlan 2013-06-19 23:56:38 +10:00
parent fdb230409c
commit 6676b35f46
3 changed files with 1366 additions and 713 deletions

File diff suppressed because it is too large Load Diff

244
pep-0426/pymeta-schema.json Normal file
View File

@ -0,0 +1,244 @@
{
"id": "http://www.python.org/dev/peps/pep-0426/",
"$schema": "http://json-schema.org/draft-04/schema#",
"title": "Metadata for Python Software Packages 2.0",
"type": "object",
"properties": {
"metadata_version": {
"description": "Version of the file format",
"type": "string",
"pattern": "^(\d+(\.\d+)*)$"
},
"name": {
"description": "The name of the distribution.",
"type": "string",
"pattern": "^[0-9A-Za-z]([0-9A-Za-z_.-]*[0-9A-Za-z])?$"
},
"version": {
"description": "The distribution's public version identifier",
"type": "string",
"pattern": "^(\d+(\.\d+)*)((a|b|c|rc)(\d+))?(\.(post)(\d+))?(\.(dev)(\d+))?$"
},
"source_label": {
"description": "A constrained identifying text string",
"type": "string",
"pattern": "^[0-9a-z_.-+]+$"
},
"source_url": {
"description": "A string containing a full URL where the source for this specific version of the distribution can be downloaded.",
"type": "string",
"format": "uri"
},
"summary": {
"description": "A one-line summary of what the distribution does.",
"type": "string"
},
"document_names": {
"description": "Names of supporting metadata documents",
"type": "object",
"properties": {
"description": {
"type": "string",
"$ref": "#/definitions/document_name"
},
"changelog": {
"type": "string",
"$ref": "#/definitions/document_name"
},
"license": {
"type": "string",
"$ref": "#/definitions/document_name"
}
},
"additionalProperties": false
},
"keywords": {
"description": "A list of additional keywords to be used to assist searching for the distribution in a larger catalog.",
"type": "array",
"items": {
"type": "string"
}
},
"license": {
"description": "A string indicating the license covering the distribution.",
"type": "string"
},
"classifiers": {
"description": "A list of strings, with each giving a single classification value for the distribution.",
"type": "array",
"items": {
"type": "string"
}
},
"contacts": {
"description": "A list of contributor entries giving the recommended contact points for getting more information about the project.",
"type": "array",
"items": {
"type": "object",
"$ref": "#/definitions/contact"
}
},
"contributors": {
"description": "A list of contributor entries for other contributors not already listed as current project points of contact.",
"type": "array",
"items": {
"type": "object",
"$ref": "#/definitions/contact"
}
},
"project_urls": {
"description": "A mapping of arbitrary text labels to additional URLs relevant to the project.",
"type": "object"
},
"extras": {
"description": "A list of optional sets of dependencies that may be used to define conditional dependencies in \"may_require\" and similar fields.",
"type": "array",
"items": {
"type": "string",
"$ref": "#/definitions/extra_name"
}
},
"distributes": {
"description": "A list of subdistributions made available through this metadistribution.",
"type": "array",
"$ref": "#/definitions/dependencies"
},
"may_distribute": {
"description": "A list of subdistributions that may be made available through this metadistribution, based on the extras requested and the target deployment environment.",
"$ref": "#/definitions/conditional_dependencies"
},
"run_requires": {
"description": "A list of other distributions needed when to run this distribution.",
"type": "array",
"$ref": "#/definitions/dependencies"
},
"run_may_require": {
"description": "A list of other distributions that may be needed when this distribution is deployed, based on the extras requested and the target deployment environment.",
"$ref": "#/definitions/conditional_dependencies"
},
"test_requires": {
"description": "A list of other distributions needed when this distribution is tested.",
"type": "array",
"$ref": "#/definitions/dependencies"
},
"test_may_require": {
"description": "A list of other distributions that may be needed when this distribution is tested, based on the extras requested and the target deployment environment.",
"type": "array",
"$ref": "#/definitions/conditional_dependencies"
},
"build_requires": {
"description": "A list of other distributions needed when this distribution is built.",
"type": "array",
"$ref": "#/definitions/dependencies"
},
"build_may_require": {
"description": "A list of other distributions that may be needed when this distribution is built, based on the extras requested and the target deployment environment.",
"type": "array",
"$ref": "#/definitions/conditional_dependencies"
},
"dev_requires": {
"description": "A list of other distributions needed when this distribution is developed.",
"type": "array",
"$ref": "#/definitions/dependencies"
},
"dev_may_require": {
"description": "A list of other distributions that may be needed when this distribution is developed, based on the extras requested and the target deployment environment.",
"type": "array",
"$ref": "#/definitions/conditional_dependencies"
},
"provides": {
"description": "A list of strings naming additional dependency requirements that are satisfied by installing this distribution. These strings must be of the form Name or Name (Version), as for the requires field.",
"type": "array",
"items": {
"type": "string"
}
},
"obsoleted_by": {
"description": "A string that indicates that this project is no longer being developed. The named project provides a substitute or replacement.",
"type": "string",
"$ref": "#/definitions/version_specifier"
},
"supports_environments": {
"description": "A list of strings specifying the environments that the distribution explicitly supports.",
"type": "array",
"items": {
"type": "string",
"$ref": "#/definitions/environment_marker"
}
},
"metabuild_hooks": {
"description": "The metabuild_hooks field is used to define various operations that may be invoked on a distribution in a platform independent manner.",
"type": "object"
},
"extensions": {
"description": "Extensions to the metadata may be present in a mapping under the 'extensions' key.",
"type": "object"
}
},
"required": ["metadata_version", "name", "version"],
"additionalProperties": false,
"definitions": {
"contact": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"email": {
"type": "string"
},
"url": {
"type": "string"
},
"role": {
"type": "string"
}
},
"required": ["name"],
"additionalProperties": false
},
"dependencies": {
"type": "array",
"items": {
"type": "string",
"$ref": "#/definitions/version_specifier"
}
},
"conditional_dependencies": {
"type": "array",
"items": {
"type": "object",
"properties": {
"extra": {
"type": "string",
"$ref": "#/definitions/extra_name"
},
"environment": {
"type": "string",
"$ref": "#/definitions/environment_marker"
},
"dependencies": {
"type": "array",
"$ref": "#/definitions/dependencies"
}
},
"required": ["dependencies"],
"additionalProperties": false
}
},
"version_specifier": {
"type": "string"
},
"extra_name": {
"type": "string"
},
"environment_marker": {
"type": "string"
},
"document_name": {
"type": "string"
}
}
}

View File

@ -27,7 +27,7 @@ standardised approach to versioning, as described in PEP 345 and PEP 386.
This PEP was broken out of the metadata 2.0 specification in PEP 426. This PEP was broken out of the metadata 2.0 specification in PEP 426.
Unlike PEP 426, the notes that remain in this document are intended as Unlike PEP 426, the notes that remain in this document are intended as
part of the final specification. part of the final specification (except for this one).
Definitions Definitions
@ -40,7 +40,7 @@ document are to be interpreted as described in RFC 2119.
The following terms are to be interpreted as described in PEP 426: The following terms are to be interpreted as described in PEP 426:
* "Distributions" * "Distributions"
* "Versions" * "Releases"
* "Build tools" * "Build tools"
* "Index servers" * "Index servers"
* "Publication tools" * "Publication tools"
@ -52,9 +52,13 @@ The following terms are to be interpreted as described in PEP 426:
Version scheme Version scheme
============== ==============
Distribution versions are identified by both a public version identifier, Distributions are identified by a public version identifier which
which supports all defined version comparison operations, and a build supports all defined version comparison operations
label, which supports only strict equality comparisons.
Distributions may also define a source label, which is not used by
automated tools. Source labels are useful when a project internal
versioning scheme requires translation to create a compliant public
version identifier.
The version scheme is used both to describe the distribution version The version scheme is used both to describe the distribution version
provided by a particular distribution archive, as well as to place provided by a particular distribution archive, as well as to place
@ -84,7 +88,7 @@ Public version identifiers are separated into up to four segments:
* Post-release segment: ``.postN`` * Post-release segment: ``.postN``
* Development release segment: ``.devN`` * Development release segment: ``.devN``
Any given version will be a "release", "pre-release", "post-release" or Any given release will be a "final release", "pre-release", "post-release" or
"developmental release" as defined in the following sections. "developmental release" as defined in the following sections.
.. note:: .. note::
@ -105,28 +109,37 @@ Source labels
Source labels are text strings with minimal defined semantics. Source labels are text strings with minimal defined semantics.
To ensure source labels can be readily incorporated as part of file names To ensure source labels can be readily incorporated as part of file names
and URLs, they MUST be comprised of only ASCII alphanumerics, plus signs, and URLs, and to avoid formatting inconsistences in hexadecimal hash
periods and hyphens. representations they MUST be limited to the following set of permitted
characters:
In addition, source labels MUST be unique within a given distribution. * Lowercase ASCII letters (``[a-z]``)
* ASCII digits (``[0-9]``)
* underscores (``_``)
* hyphens (``-``)
* periods (``.``)
* plus signs (``+``)
As with distribution names, all comparisons of source labels MUST be case Source labels MUST start and end with an ASCII letter or digit.
insensitive.
Source labels MUST be unique within each project and MUST NOT match any
defined version for the project.
Releases Final releases
-------- --------------
A version identifier that consists solely of a release segment is termed A version identifier that consists solely of a release segment is
a "release". termed a "final release".
The release segment consists of one or more non-negative integer values, The release segment consists of one or more non-negative integer
separated by dots:: values, separated by dots::
N[.N]+ N[.N]+
Releases within a project will typically be numbered in a consistently Final releases within a project MUST be numbered in a consistently
increasing fashion. increasing fashion, otherwise automated tools will not be able to upgrade
them correctly.
Comparison and ordering of release segments considers the numeric value Comparison and ordering of release segments considers the numeric value
of each component of the release segment in turn. When comparing release of each component of the release segment in turn. When comparing release
@ -157,8 +170,8 @@ For example::
2.0 2.0
2.0.1 2.0.1
A release series is any set of release numbers that start with a common A release series is any set of final release numbers that start with a
prefix. For example, ``3.3.1``, ``3.3.5`` and ``3.3.9.45`` are all common prefix. For example, ``3.3.1``, ``3.3.5`` and ``3.3.9.45`` are all
part of the ``3.3`` release series. part of the ``3.3`` release series.
.. note:: .. note::
@ -206,8 +219,8 @@ of both ``c`` and ``rc`` releases for a common release segment.
Post-releases Post-releases
------------- -------------
Some projects use post-releases to address minor errors in a release that Some projects use post-releases to address minor errors in a final release
do not affect the distributed software (for example, correcting an error that do not affect the distributed software (for example, correcting an error
in the release notes). in the release notes).
If used as part of a project's development cycle, these post-releases are If used as part of a project's development cycle, these post-releases are
@ -371,7 +384,7 @@ are permitted and MUST be ordered as shown::
.devN, aN, bN, cN, rcN, <no suffix>, .postN .devN, aN, bN, cN, rcN, <no suffix>, .postN
Note that `rc` will always sort after `c` (regardless of the numeric Note that `rc` will always sort after `c` (regardless of the numeric
component) although they are semantically equivalent. Tools are free to component) although they are semantically equivalent. Tools MAY
reject this case as ambiguous and remain in compliance with the PEP. reject this case as ambiguous and remain in compliance with the PEP.
Within an alpha (``1.0a1``), beta (``1.0b1``), or release candidate Within an alpha (``1.0a1``), beta (``1.0b1``), or release candidate
@ -506,6 +519,22 @@ numbering based on API compatibility, as well as triggering more appropriate
version comparison semantics. version comparison semantics.
Olson database versioning
~~~~~~~~~~~~~~~~~~~~~~~~~
The ``pytz`` project inherits its versioning scheme from the corresponding
Olson timezone database versioning scheme: the year followed by a lowercase
character indicating the version of the database within that year.
This can be translated to a compliant 3-part version identifier as
``0.<year>.<serial>``, where the serial starts at zero (for the '<year>a'
release) and is incremented with each subsequent database update within the
year.
As with other translated version identifiers, the corresponding Olson
database version would be recorded in the source label field.
Version specifiers Version specifiers
================== ==================
@ -521,7 +550,7 @@ clause:
* ``~=``: `Compatible release`_ clause * ``~=``: `Compatible release`_ clause
* ``==``: `Version matching`_ clause * ``==``: `Version matching`_ clause
* ``!=``: `Version exclusion`_ clause * ``!=``: `Version exclusion`_ clause
* ``is``: `Source reference`_ clause * ``is``: `Direct reference`_ clause
* ``<=``, ``>=``: `Inclusive ordered comparison`_ clause * ``<=``, ``>=``: `Inclusive ordered comparison`_ clause
* ``<``, ``>``: `Exclusive ordered comparison`_ clause * ``<``, ``>``: `Exclusive ordered comparison`_ clause
@ -605,6 +634,11 @@ version. The *only* substitution performed is the zero padding of the
release segment to ensure the release segments are compared with the same release segment to ensure the release segments are compared with the same
length. length.
Whether or not strict version matching is appropriate depends on the specific
use case for the version specifier. Automated tools SHOULD at least issue
warnings and MAY reject them entirely when strict version matches are used
inappropriately.
Prefix matching may be requested instead of strict comparison, by appending Prefix matching may be requested instead of strict comparison, by appending
a trailing ``.*`` to the version identifier in the version matching clause. a trailing ``.*`` to the version identifier in the version matching clause.
This means that additional trailing segments will be ignored when This means that additional trailing segments will be ignored when
@ -645,49 +679,42 @@ match or not as shown::
!= 1.1.* # Same prefix, so 1.1.post1 does not match clause != 1.1.* # Same prefix, so 1.1.post1 does not match clause
Source reference Direct reference
---------------- ----------------
A source reference includes the source reference operator ``is`` and A direct reference includes the direct reference operator ``is`` and
a source label or a source URL. an explicit URL.
Installation tools MAY also permit direct references to a platform Whether or not direct references are appropriate depends on the specific
appropriate binary archive in a source reference clause. use case for the version specifier. Automated tools SHOULD at least issue
warnings and MAY reject them entirely when direct references are used
inappropriately.
Publication tools and public index servers SHOULD NOT permit direct Depending on the use case, some appropriate targets for a direct URL
references to a platform appropriate binary archive in a source reference are a source archive, an sdist, a wheel binary archive or a
reference clause. direct reference to a tag or specific commit in an online version control
system. The exact URLs and targets supported will be automated tool
Source label matching works solely on strict equality comparisons: the specific.
candidate source label must be exactly the same as the source label in the
version clause for the clause to match the candidate distribution.
For example, a source reference could be used to depend directly on a
version control hash based identifier rather than the translated public
version::
exact-dependency (is 1.3.7+build.11.e0f985a)
A source URL is distinguished from a source label by the presence of
``:`` and ``/`` characters in the source reference. As these characters
are not permitted in source labels, they indicate that the reference uses
a source URL.
Some appropriate targets for a source URL are a source tarball, an sdist
archive or a direct reference to a tag or specific commit in an online
version control system. The exact URLs and
targets supported will be installation tool specific.
For example, a local source archive may be referenced directly:: For example, a local source archive may be referenced directly::
pip (is file:///localbuilds/pip-1.3.1.zip) pip (is file:///localbuilds/pip-1.3.1.zip)
All source URL references SHOULD either specify a local file URL, a secure Alternatively, a prebuilt archive may also be referenced::
transport mechanism (such as ``https``) or else include an expected hash
value in the URL for verification purposes. If an insecure network pip (is file:///localbuilds/pip-1.3.1-py33-none-any.whl)
transport is specified without any hash information (or with hash
information that the tool doesn't understand), automated tools SHOULD
at least emit a warning and MAY refuse to rely on the URL. All direct URL references that do not refer to a local file URL SHOULD
specify a secure transport mechanism (such as ``https``), include an
expected hash value in the URL for verification purposes, or both. If an
insecure transport is specified without any hash information, with hash
information that the tool doesn't understand, or with a selected hash
algortihm that the tool considers too weak to trust, automated tools
SHOULD at least emit a warning and MAY refuse to rely on the URL.
Index servers MAY place additional restrictions on direct references (such
as requiring all references be to files hosted on the index server itself).
It is RECOMMENDED that only hashes which are unconditionally provided by It is RECOMMENDED that only hashes which are unconditionally provided by
the latest version of the standard library's ``hashlib`` module be used the latest version of the standard library's ``hashlib`` module be used
@ -695,24 +722,17 @@ for source archive hashes. At time of writing, that list consists of
``'md5'``, ``'sha1'``, ``'sha224'``, ``'sha256'``, ``'sha384'``, and ``'md5'``, ``'sha1'``, ``'sha224'``, ``'sha256'``, ``'sha384'``, and
``'sha512'``. ``'sha512'``.
For source archive references, an expected hash value may be For source archive and wheel references, an expected hash value may be
specified by including a ``<hash-algorithm>=<expected-hash>`` as part of specified by including a ``<hash-algorithm>=<expected-hash>`` as part of
the URL fragment. the URL fragment.
For version control references, the ``VCS+protocol`` scheme SHOULD be Version control references, the ``VCS+protocol`` scheme SHOULD be
used to identify both the version control system and the secure transport. used to identify both the version control system and the secure transport.
To support version control systems that do not support including commit or To support version control systems that do not support including commit or
tag references directly in the URL, that information may be appended to the tag references directly in the URL, that information may be appended to the
end of the URL using the ``@<tag>`` notation. end of the URL using the ``@<tag>`` notation.
The use of ``is`` when defining dependencies for published distributions
is strongly discouraged as it greatly complicates the deployment of
security fixes. The source label matching operator is intended primarily
for use when defining dependencies for repeatable *deployments of
applications* while using a shared distribution index, as well as to
reference dependencies which are not published through an index server.
Inclusive ordered comparison Inclusive ordered comparison
---------------------------- ----------------------------
@ -752,62 +772,47 @@ Handling of pre-releases
------------------------ ------------------------
Pre-releases of any kind, including developmental releases, are implicitly Pre-releases of any kind, including developmental releases, are implicitly
excluded from all version specifiers, *unless* a pre-release or developmental excluded from all version specifiers, *unless* they are already present
release is explicitly mentioned in one of the clauses. For example, these on the system, explicitly requested by the user, or if the only available
specifiers implicitly exclude all pre-releases and development version that satisfies the version specifier is a pre-release.
releases of later versions::
2.2
>= 1.0
While these specifiers would include at least some of them::
2.2.dev0
2.2, != 2.3b2
>= 1.0a1
>= 1.0c1
>= 1.0, != 1.0b2
>= 1.0, < 2.0.dev123
By default, dependency resolution tools SHOULD: By default, dependency resolution tools SHOULD:
* accept already installed pre-releases for all version specifiers * accept already installed pre-releases for all version specifiers
* accept remotely available pre-releases for version specifiers which * accept remotely available pre-releases for version specifiers where
include at least one version clauses that references a pre-release there is no final or post release that satisfies the version specifier
* exclude all other pre-releases from consideration * exclude all other pre-releases from consideration
Dependency resolution tools MAY issue a warning if a pre-release is needed
to satisfy a version specifier.
Dependency resolution tools SHOULD also allow users to request the Dependency resolution tools SHOULD also allow users to request the
following alternative behaviours: following alternative behaviours:
* accepting pre-releases for all version specifiers * accepting pre-releases for all version specifiers
* excluding pre-releases for all version specifiers (reporting an error or * excluding pre-releases for all version specifiers (reporting an error or
warning if a pre-release is already installed locally) warning if a pre-release is already installed locally, or if a
pre-release is the only way to satisfy a particular specifier)
Dependency resolution tools MAY also allow the above behaviour to be Dependency resolution tools MAY also allow the above behaviour to be
controlled on a per-distribution basis. controlled on a per-distribution basis.
Post-releases and purely numeric releases receive no special treatment in Post-releases and final releases receive no special treatment in version
version specifiers - they are always included unless explicitly excluded. specifiers - they are always included unless explicitly excluded.
Examples Examples
-------- --------
* ``3.1``: version 3.1 or later, but not * ``3.1``: version 3.1 or later, but not version 4.0 or later.
version 4.0 or later. Excludes pre-releases and developmental releases. * ``3.1.2``: version 3.1.2 or later, but not version 3.2.0 or later.
* ``3.1.2``: version 3.1.2 or later, but not * ``3.1a1``: version 3.1a1 or later, but not version 4.0 or later.
version 3.2.0 or later. Excludes pre-releases and developmental releases.
* ``3.1a1``: version 3.1a1 or later, but not
version 4.0 or later. Allows pre-releases like 3.2a4 and developmental
releases like 3.2.dev1.
* ``== 3.1``: specifically version 3.1 (or 3.1.0), excludes all pre-releases, * ``== 3.1``: specifically version 3.1 (or 3.1.0), excludes all pre-releases,
post releases, developmental releases and any 3.1.x maintenance releases. post releases, developmental releases and any 3.1.x maintenance releases.
* ``== 3.1.*``: any version that starts with 3.1, excluding pre-releases and * ``== 3.1.*``: any version that starts with 3.1. Equivalent to the
developmental releases. Equivalent to the ``3.1.0`` compatible release ``3.1.0`` compatible release clause.
clause.
* ``3.1.0, != 3.1.3``: version 3.1.0 or later, but not version 3.1.3 and * ``3.1.0, != 3.1.3``: version 3.1.0 or later, but not version 3.1.3 and
not version 3.2.0 or later. Excludes pre-releases and developmental not version 3.2.0 or later.
releases.
Updating the versioning specification Updating the versioning specification
@ -825,28 +830,29 @@ Summary of differences from \PEP 386
* Moved the description of version specifiers into the versioning PEP * Moved the description of version specifiers into the versioning PEP
* added the "source label" concept to better handle projects that wish to * Aadded the "source label" concept to better handle projects that wish to
use a non-compliant versioning scheme internally, especially those based use a non-compliant versioning scheme internally, especially those based
on DVCS hashes on DVCS hashes
* added the "compatible release" clause * Added the "compatible release" clause
* added the "source reference" clause * Added the "direct reference" clause
* added the trailing wildcard syntax for prefix based version matching * Added the trailing wildcard syntax for prefix based version matching
and exclusion and exclusion
* changed the top level sort position of the ``.devN`` suffix * Changed the top level sort position of the ``.devN`` suffix
* allowed single value version numbers * Allowed single value version numbers
* explicit exclusion of leading or trailing whitespace * Explicit exclusion of leading or trailing whitespace
* explicit criterion for the exclusion of date based versions * Explicit criterion for the exclusion of date based versions
* implicitly exclude pre-releases unless explicitly requested * Implicitly exclude pre-releases unless they're already present or
needed to satisfy a dependency
* treat post releases the same way as unqualified releases * Treat post releases the same way as unqualified releases
* Discuss ordering and dependencies across metadata versions * Discuss ordering and dependencies across metadata versions
@ -995,11 +1001,12 @@ The previous interpretation also excluded post-releases from some version
specifiers for no adequately justified reason. specifiers for no adequately justified reason.
The updated interpretation is intended to make it difficult to accidentally The updated interpretation is intended to make it difficult to accidentally
accept a pre-release version as satisfying a dependency, while allowing accept a pre-release version as satisfying a dependency, while still
pre-release versions to be explicitly requested when needed. allowing pre-release versions to be retrieved automatically when that's the
only way to satisfy a dependency.
The "some forward compatibility assumed" default version constraint is The "some forward compatibility assumed" default version constraint is
taken directly from the Ruby community's "pessimistic version constraint" derived from the Ruby community's "pessimistic version constraint"
operator [2]_ to allow projects to take a cautious approach to forward operator [2]_ to allow projects to take a cautious approach to forward
compatibility promises, while still easily setting a minimum required compatibility promises, while still easily setting a minimum required
version for their dependencies. It is made the default behaviour rather version for their dependencies. It is made the default behaviour rather
@ -1022,16 +1029,17 @@ improved tools for dynamic path manipulation.
The trailing wildcard syntax to request prefix based version matching was The trailing wildcard syntax to request prefix based version matching was
added to make it possible to sensibly define both compatible release clauses added to make it possible to sensibly define both compatible release clauses
and the desired pre-release handling semantics for ``<`` and ``>`` ordered and the desired pre- and post-release handling semantics for ``<`` and ``>``
comparison clauses. ordered comparison clauses.
Source references are added for two purposes. In conjunction with source Direct references are added as an "escape clause" to handle messy real
labels, they allow hash based references to exact versions that aren't world situations that don't map neatly to the standard distribution model.
compliant with the fully ordered public version scheme, such as those This includes dependencies on unpublished software for internal use, as well
generated from version control. In combination with source URLs, they as handling the more complex compatibility issues that may arise when
also allow the new metadata standard to natively support an existing wrapping third party libraries as C extensions (this is of especial concern
feature of ``pip``, which allows arbitrary URLs like to the scientific community). Index servers are given a lot of freedom to
``file:///localbuilds/exampledist-1.0-py33-none-any.whl``. disallow them, since they're intended primarily as a tool for integrators
rather than publishers.
References References