Commits

Nick Coghlan committed a20d7a5

pydist.json -> pysource.json

Comments (0)

Files changed (2)

core-metadata.rst

    * PEP 440, covering the versioning identification and selection scheme
    * PEP 459, covering several standard extensions
    * a yet-to-be-written PEP to define v2.0 of the sdist format
-   * an updated wheel PEP (v1.1) to add pydist.json (and possibly convert
+   * an updated wheel PEP (v1.1) to add pysource.json (and possibly convert
      the wheel metadata file from Key:Value to JSON)
-   * an updated installation database PEP to add pydist.json
+   * an updated installation database PEP to add pysource.json
    * a PEP to standardise the expected command line interface for setup.py
      as an interface to an application's build system (rather than requiring
      that the build system support the distutils command system)
 Metadata files
 --------------
 
-The information defined in this PEP is serialised to ``pydist.json``
+The information defined in this PEP is serialised to ``pysource.json``
 files for some use cases. These are files containing UTF-8 encoded JSON
 metadata.
 
 
 There are three standard locations for these metadata files:
 
-* as a ``{distribution}-{version}.dist-info/pydist.json`` file in an
+* as a ``{distribution}-{version}.dist-info/pysource.json`` file in an
   ``sdist`` source distribution archive
-* as a ``{distribution}-{version}.dist-info/pydist.json`` file in a ``wheel``
+* as a ``{distribution}-{version}.dist-info/pysource.json`` file in a ``wheel``
   binary distribution archive
-* as a ``{distribution}-{version}.dist-info/pydist.json`` file in a local
+* as a ``{distribution}-{version}.dist-info/pysource.json`` file in a local
   Python installation database
 
 .. note::
 Note that these metadata files SHOULD NOT be processed if the version of the
 containing location is too low to indicate that they are valid. Specifically,
 unversioned ``sdist`` archives, unversioned installation database directories
-and version 1.0 of the ``wheel`` specification do not cover ``pydist.json``
+and version 1.0 of the ``wheel`` specification do not cover ``pysource.json``
 files.
 
 Other tools involved in Python distribution MAY also use this format.
 
 A `jsonschema <https://pypi.python.org/pypi/jsonschema>`__ description of
 the distribution metadata is `available
-<http://hg.python.org/peps/file/default/pep-0426/pydist-schema.json>`__.
+<http://hg.python.org/peps/file/default/pep-0426/pysource-schema.json>`__.
 
 This schema does NOT currently handle validation of some of the more complex
 string fields (instead treating them as opaque strings).
 easy to distribute 1.x and 2.x metadata in parallel, greatly simplifying
 several aspects of the migration to the new metadata format.
 
+The specific choice of ``pysource.json`` as the preferred file name relates
+to the fact that the metadata described in these files is defined at the
+time of creating the *source* archive for a distribution. Additional
+metadata formats may be defined in the future to hold information that can
+only be determined after building a binary distribution for a particular
+target environment.
+
 
 Changing the version scheme
 ---------------------------
 MIME type registration
 ----------------------
 
-At some point after acceptance of the PEP, I will likely submit the
+At some point after acceptance of the PEP, we may submit the
 following MIME type registration requests to IANA:
 
-* Full metadata: ``application/vnd.python.pydist+json``
+* Full metadata: ``application/vnd.python.pysource+json``
 * Essential dependency resolution metadata:
-  ``application/vnd.python.pydist-dependencies+json``
+  ``application/vnd.python.pysource-dependencies+json``
 
 It's even possible we may be able to just register the ``vnd.python``
 namespace under the banner of the PSF rather than having to register
 specifier like ``pip (>= 1.5)``.
 
 The hyphen is chosen primarily for readability of local version identifiers.
-While the wheel format also uses hyphens as separators between components,
-the escaping rules defined in PEP 427, a future iteration of the wheel
-specification will likely end up replacing the current optional "build tag"
-component of the wheel file naming scheme with the "local version label"
-component from this PEP.
-
-By permitting the use of local version identifiers for binary distributions,
-even on public index servers, and allowing the use of "+" characters in
-local version labels, this change combines with the introduction of
-source labels to make it possible to include build tags in distribution
-metadata, without interfering with the requirement for fully ordered
-public version identifiers.
+As the wheel format also uses hyphens as separators between components, the
+"local version label" component from this PEP should be mapped to the
+optional "build tag" component of the wheel file naming scheme, rather than
+allowing the hyphen to be transformed according the normal PEP 427 escaping
+rules.
 
 
 References