iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP-0691 Gramatical changes + `meta` key description under Project List (#2677) 

* Grammer fixes and TODO's

* Added missing meta key to Project List description
This commit is contained in:
Wouter Koorn 2022-06-27 19:14:09 +02:00 committed by GitHub
parent c4ec86fcd3
commit 5dd9452ce4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 14 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
pep-0691.rst
View File

@ -51,7 +51,7 @@ did not propose any large changes to the API.
In the intervening years, we've regularly talked about an "API V2" that would
re-envision the entire API of PyPI. However, due to limited time constraints,
that effort has not gained much, if, any traction beyond people thinking that
that effort has not gained much, if any, traction beyond people thinking that
it would be nice to do.
This PEP attempts to take a different route. It doesn't fundamentally change
@ -99,7 +99,7 @@ Goals
Specification
=============
To enable parsing responses with only the standard library, this PEP specifies that
To enable response parsing with only the standard library, this PEP specifies that
all responses (besides the files themselves, and the HTML responses from
:pep:`503`) should be serialized using `JSON <https://www.json.org/>`_.
@ -122,7 +122,7 @@ Similar to :pep:`629`, the major version number **MUST** be incremented if any
changes to the new format would result in no longer being able to expect existing
clients to meaningfully understand the format.
Likewise, incrementing the minor version **MUST** be incremented if features are
Likewise, the minor version **MUST** be incremented if features are
added or removed from the format, but existing clients would be expected to continue
to meaningfully understand the format.
@ -172,7 +172,7 @@ PEP:
* All JSON responses will have a ``meta.api-version`` key, which will be a string that
contains the :pep:`629` ``Major.Minor`` version number, with the same fail/warn
semantics as in :pep:`629`.
semantics as defined in :pep:`629`.
* All requirements of :pep:`503` that are not HTML specific still apply.
@ -181,9 +181,11 @@ Project List
~~~~~~~~~~~~
The root URL ``/`` for this PEP (which represents the base URL) will be a JSON encoded
dictionary which has a single key, ``projects``, which is an array where each entry
is a dictionary with a single key, ``name``, which represents string of the project
name. As an example:
dictionary which has a two keys:
- ``projects``: An array where each entry is a dictionary with a single key, ``name``, which represents string of the project name.
- ``meta``: The general response metadata as `described earlier <json-serialization_>`__.
As an example:
.. code-block:: json
@ -355,8 +357,8 @@ Version + Format Selection
--------------------------
Now that there is multiple possible serializations, we need a mechanism to allow
clients to indicate what serialization formats that they're able to understand. In
addition, it would be a benefit if any possible new major version to the API can
clients to indicate what serialization formats they're able to understand. In
addition, it would be beneficial if any possible new major version to the API can
be added without disrupting existing clients expecting the previous API version.
To enable this, this PEP standardizes on the use of HTTP's
@ -512,7 +514,8 @@ Servers that implement the Simple API may choose to support an URL parameter nam
``format`` to allow the clients to request a specific version of the URL.
The value of the ``format`` parameter should be **one** of the valid content types.
Passing multiple content types, wild cards, quality values, etc is **not** supported.
Passing multiple content types, wild cards, quality values, etc... is **not**
supported.
Supporting this parameter is optional, and clients **SHOULD NOT** rely on it for
interacting with the API. This negotiation mechanism is intended to allow for easier
@ -587,7 +590,7 @@ modified to include the API version and serialization format using something lik
``simple/PROJECT/vnd.pypi.simple.v1.json``.
In this case, since ``text/html`` is an alias to ``application/vnd.pypi.simple.v1+html``
when interacting through TUF, likely it will make the most sense to normalize to the
when interacting through TUF, it likely will make the most sense to normalize to the
more explicit name.
Likewise the ``latest`` metaversion should not be included in the targets, only