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

PEP 592: Typo fixes & restructuring (#1043)

This commit is contained in:
Donald Stufft 2019-05-10 11:37:42 -04:00 committed by GitHub
parent 8ac1ec8fe6
commit 1e8f07b877
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 32 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
pep-0592.rst
View File

@ -82,16 +82,6 @@ the future (and once rescinded, may be reset as well). Thus API users
**MUST** be able to cope with a yanked file being "unyanked" (and even
yanked again).
Whenever a file has been yanked or unyanked, an entry will be recorded
in the journal using one of the following string patterns:
* Yanking a single file: ``yank file {filename}``.
* Unkyanking a single file: ``unyank file {filename}``.
If an entire release has been yanked, this will be recorded in the
journal as a seperate event for yanking each individual file that
is part of that release.
Installers
----------
@ -107,7 +97,7 @@ An installer **MUST** ignore yanked releases, if the selection constraints
can be satisified with a non-yanked version, and **MAY** refuse to use a
yanked release even if it means that the request cannot be satisfied at all.
An implementation **SHOULD** choose a policy that follows the spirit of the
intention above, and that prevents "new" dependnecies on yanked
intention above, and that prevents "new" dependencies on yanked
releases/files.
What this means is left up to the specific installer, to decide how to best
@ -121,7 +111,7 @@ suggested approaches to take:
be done as per PEP 440 for things like local versions, zero padding,
etc.
2. Yanked files are always ignored, unless they are the only file that
matches what a lock file (such as ``Pipfile.lock`` or ``poetry.lock``
matches what a lock file (such as ``Pipfile.lock`` or ``poetry.lock``)
specifies to be installed. In this case, a yanked file **SHOULD** not
be used when creating or updating a lock file from some input file or
command.
@ -144,7 +134,7 @@ Mirrors can generally treat yanked files one of two ways:
2. They may choose to include yanked files, and additionally mirror the
``data-yanked`` attribute as well.
Mirrors **SHOULD NOT** mirror a yanked file without also mirroring the
Mirrors **MUST NOT** mirror a yanked file without also mirroring the
``data-yanked`` attribute for it.
@ -172,6 +162,35 @@ idea has been rejected, favoring instead to use additional attributes
if the need ever arose.
Warehouse/PyPI Implementation Notes
===================================
While this PEP implements yanking at the file level, that is largely
due to the shape the simple repository API takes, not a specific
decision made by this PEP.
In Warehouse, the user experience will be implemented in terms of
yanking or unyanking an entire release, rather than as an operation on
individual files, which will then be exposed via the API as individual
files being yanked.
Other repository implementations may choose to to expose this capability
in a different way, or not expose it at all.
Journal Handling
----------------
Whenever a release has been yanked, an entry will be recorded in the
journal using one of the following string patterns:
* ``yank release``
* ``unyank release``
In both cases, the standard journal structure will indicate which release
of which project has been yanked or unyanked.
.. _`Simple Repository API`:
https://packaging.python.org/specifications/simple-repository-api/