Skip to content

Commit caf1140

Browse files
committed
simple-repository-api: clean up, add API history
Signed-off-by: William Woodruff <[email protected]>
1 parent 83103b2 commit caf1140

File tree

1 file changed

+79
-72
lines changed

1 file changed

+79
-72
lines changed

source/specifications/simple-repository-api.rst

Lines changed: 79 additions & 72 deletions
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,11 @@
55
Simple repository API
66
=====================
77

8+
The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
9+
"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
10+
and "**OPTIONAL**"" in this document are to be interpreted as described in
11+
:rfc:`2119`.
12+
813
The interface for querying available package versions and
914
retrieving packages from an index server comes in two forms:
1015
HTML and JSON.
@@ -28,7 +33,9 @@ Within a repository, the root URL (``/`` for this spec which represents the base
2833
URL) **MUST** be a valid HTML5 page with a single anchor element per project in
2934
the repository. The text of the anchor tag **MUST** be the name of
3035
the project and the href attribute **MUST** link to the URL for that particular
31-
project. As an example::
36+
project. As an example:
37+
38+
.. code-block:: html
3239

3340
<!DOCTYPE html>
3441
<html>
@@ -89,7 +96,9 @@ In addition to the above, the following constraints are placed on the API:
8996
link. This exposes the :ref:`core-metadata-requires-python` metadata field
9097
for the corresponding release. Where this is present, installer tools
9198
**SHOULD** ignore the download when installing to a Python version that
92-
doesn't satisfy the requirement. For example::
99+
doesn't satisfy the requirement. For example:
100+
101+
.. code-block:: html
93102

94103
<a href="..." data-requires-python="&gt;=3">...</a>
95104

@@ -209,13 +218,15 @@ Versioning PyPI's Simple API
209218

210219
This spec proposes the inclusion of a meta tag on the responses of every
211220
successful request to a simple API page, which contains a name attribute
212-
of "pypi:repository-version", and a content that is a :ref:`version specifiers
221+
of ``pypi:repository-version``, and a content that is a :ref:`version specifiers
213222
specification <version-specifiers>` compatible
214223
version number, which is further constrained to ONLY be Major.Minor, and
215224
none of the additional features supported by :ref:`the version specifiers
216225
specification <version-specifiers>`.
217226

218-
This would end up looking like::
227+
This would end up looking like:
228+
229+
.. code-block:: html
219230

220231
<meta name="pypi:repository-version" content="1.3">
221232

@@ -241,10 +252,18 @@ is included to disambiguate with future versions (e.g. a hypothetical
241252
simple api v2 that lived at /v2/, but which would be confusing if the
242253
repository-version was set to a version >= 2).
243254

244-
This spec sets the current API version to "1.0", and expects that
245-
future specs that further evolve the simple API will increment the
246-
minor version number.
255+
API Version History
256+
-------------------
257+
258+
This section contains only an abbreviated history of changes,
259+
as marked by the API version number. For a full history of changes including
260+
changes made before API versioning, see :ref:`History <simple-repository-history>`.
247261

262+
- API version 1.0: Initial version of the API, declared with :pep:`629`.
263+
- API version 1.1: Added ``versions``, ``files[].size``, and ``files[].upload-time`` metadata
264+
to the JSON serialization, declared with :pep:`700`.
265+
- API version 1.2: Added repository "tracks" metadata, declared with :pep:`708`.
266+
- API version 1.3: Added provenance metadata, declared with :pep:`740`.
248267

249268
Clients
250269
-------
@@ -393,6 +412,8 @@ spec:
393412
* All requirements of :ref:`the base HTML API specification
394413
<simple-repository-api-base>` that are not HTML specific still apply.
395414

415+
* Keys (at any level) with a leading underscore are reserved as private for
416+
index server use. No future standard will assign a meaning to any such key.
396417

397418
Project List
398419
~~~~~~~~~~~~
@@ -446,11 +467,34 @@ The format of this URL is ``/<project>/`` where the ``<project>`` is replaced by
446467
name for that project, so a project named "Silly_Walk" would
447468
have a URL like ``/silly-walk/``.
448469

449-
This URL must respond with a JSON encoded dictionary that has three keys:
470+
This URL must respond with a JSON encoded dictionary that has four keys:
450471

451472
- ``name``: The normalized name of the project.
452473
- ``files``: A list of dictionaries, each one representing an individual file.
453474
- ``meta``: The general response metadata as `described earlier <json-serialization_>`__.
475+
- ``versions``: A list of version strings specifying all of the project versions
476+
uploaded for this project. The value of ``versions`` is logically a set,
477+
and as such may not contain duplicates, and the order of the versions is
478+
not significant.
479+
480+
.. note::
481+
482+
All of the files listed in the ``files`` key MUST be associated with one of the
483+
versions in the ``versions`` key. The ``versions`` key MAY contain versions with
484+
no associated files (to represent versions with no files uploaded, if the server
485+
has such a concept).
486+
487+
.. note::
488+
489+
Because servers may hold "legacy" data from before the adoption of
490+
:ref:`the version specifiers specification (VSS) <version-specifiers>`, version
491+
strings currently cannot be required to be valid VSS versions, and therefore
492+
cannot be assumed to be orderable using the VSS rules. However, servers **SHOULD**
493+
use normalized VSS versions where possible.
494+
495+
.. note::
496+
497+
The ``versions`` key was added with API version 1.1.
454498

455499
Each individual file dictionary has the following keys:
456500

@@ -508,6 +552,25 @@ Each individual file dictionary has the following keys:
508552
and is a truthy value, then it **SHOULD** be interpreted as indicating that the
509553
file pointed to by the ``url`` field has been "Yanked" as per :ref:`the API
510554
yank specification <simple-repository-api-yank>`.
555+
- ``size``: A **mandatory** key. It **MUST** contain an integer which is the file size in bytes.
556+
557+
.. note::
558+
559+
The ``size`` key was added with API version 1.1.
560+
561+
- ``upload-time``: An **optional** key that, if present, **MUST** contain a valid
562+
ISO 8601 date/time string in the format ``yyyy-mm-ddThh:mm:ss.ffffffZ``
563+
which represents the time the file was uploaded to the index.
564+
565+
As indicated by the ``Z`` suffix, the upload time **MUST** use the UTC timezone.
566+
The fractional seconds part of the timestamp (the ``.ffffff`` part) is optional,
567+
and if present may contain up to 6 digits of precision. If a server does not record
568+
upload time information for a file, it **MAY** omit the ``upload-time`` key.
569+
570+
.. note::
571+
572+
The ``upload-time`` key was added with API version 1.1.
573+
511574
- ``provenance``: An **optional** key which, if present **MUST** be either a JSON
512575
string or ``null``. If not ``null``, it **MUST** be a URL to the file's
513576
associated provenance, with the same rules as ``data-provenance`` in the
@@ -532,17 +595,20 @@ As an example:
532595
"url": "https://example.com/files/holygrail-1.0.tar.gz",
533596
"hashes": {"sha256": "...", "blake2b": "..."},
534597
"requires-python": ">=3.7",
535-
"yanked": "Had a vulnerability"
598+
"yanked": "Had a vulnerability",
599+
"size": 123456
536600
},
537601
{
538602
"filename": "holygrail-1.0-py3-none-any.whl",
539603
"url": "https://example.com/files/holygrail-1.0-py3-none-any.whl",
540604
"hashes": {"sha256": "...", "blake2b": "..."},
541605
"requires-python": ">=3.7",
542606
"dist-info-metadata": true,
543-
"provenance": "https://example.com/files/holygrail-1.0-py3-none-any.whl.provenance"
607+
"provenance": "https://example.com/files/holygrail-1.0-py3-none-any.whl.provenance",
608+
"size": 1337
544609
}
545-
]
610+
],
611+
"versions": ["1.0"]
546612
}
547613
548614
@@ -889,71 +955,10 @@ It is recommended that clients:
889955
- Check the ``Content-Type`` of the response and ensure it matches something
890956
that you were expecting.
891957

892-
Additional Fields for the Simple API for Package Indexes
893-
========================================================
894-
895-
This specification defines version 1.1 of the simple repository API. For the
896-
HTML version of the API, there is no change from version 1.0. For the JSON
897-
version of the API, the following changes are made:
898-
899-
- The ``api-version`` must specify version 1.1 or later.
900-
- A new ``versions`` key is added at the top level.
901-
- Two new "file information" keys, ``size`` and ``upload-time``, are added to
902-
the ``files`` data.
903-
- Keys (at any level) with a leading underscore are reserved as private for
904-
index server use. No future standard will assign a meaning to any such key.
905-
906-
The ``versions`` and ``size`` keys are mandatory. The ``upload-time`` key is
907-
optional.
908-
909-
Versions
910-
--------
911-
912-
An additional key, ``versions`` MUST be present at the top level, in addition to
913-
the keys ``name``, ``files`` and ``meta`` defined in :ref:`the JSON API
914-
specification <simple-repository-api-json>`. This key MUST
915-
contain a list of version strings specifying all of the project versions uploaded
916-
for this project. The value is logically a set, and as such may not contain
917-
duplicates, and the order of the values is not significant.
918-
919-
All of the files listed in the ``files`` key MUST be associated with one of the
920-
versions in the ``versions`` key. The ``versions`` key MAY contain versions with
921-
no associated files (to represent versions with no files uploaded, if the server
922-
has such a concept).
923-
924-
Note that because servers may hold "legacy" data from before the adoption of
925-
:ref:`the version specifiers specification (VSS) <version-specifiers>`, version
926-
strings currently cannot be required to be valid VSS versions, and therefore
927-
cannot be assumed to be orderable using the VSS rules. However, servers SHOULD
928-
use normalised VSS versions where
929-
possible.
930-
931-
932-
Additional file information
933-
---------------------------
934-
935-
Two new keys are added to the ``files`` key.
936-
937-
- ``size``: This field is mandatory. It MUST contain an integer which is the
938-
file size in bytes.
939-
- ``upload-time``: This field is optional. If present, it MUST contain a valid
940-
ISO 8601 date/time string, in the format ``yyyy-mm-ddThh:mm:ss.ffffffZ``,
941-
which represents the time the file was uploaded to the index. As indicated by
942-
the ``Z`` suffix, the upload time MUST use the UTC timezone. The fractional
943-
seconds part of the timestamp (the ``.ffffff`` part) is optional, and if
944-
present may contain up to 6 digits of precision. If a server does not record
945-
upload time information for a file, it MAY omit the ``upload-time`` key.
946958

947959
Rename dist-info-metadata in the Simple API
948960
===========================================
949961

950-
951-
The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
952-
"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
953-
and "**OPTIONAL**"" in this document are to be interpreted as described in
954-
:rfc:`RFC 2119 <2119>`.
955-
956-
957962
Servers
958963
-------
959964

@@ -992,6 +997,8 @@ if it is present. They
992997
**MAY** optionally use the legacy ``dist-info-metadata`` key if it is present
993998
but ``core-metadata`` is not.
994999

1000+
.. _simple-repository-history:
1001+
9951002
History
9961003
=======
9971004

0 commit comments

Comments
 (0)