Introduce PEP for pip provenance #1
Conversation
Most notably, I've removed "channels" from the PEP.
The SVG image in the "Mind the Gap" section (pep-0495-gap.svg) was incorrect. It is essentially the same as the the SVG image in the "In the Gap" section (pep-0495-fold.svg). This is a bug that dates back to the original commit on 2015-08-30 (814d372) that uploaded the both the PNG and SVG versions of the Fold and Gap images. The PNG version of the Gap image is correct, but the SVG version is incorrect. The replacement SVG image attached in this PR is a manual recreation of the PNG version of the Gap image that was deleted on 2022-04-23. It is not exactly the same, but I think it is close enough.
* Rename `--without-gil` to `--disable-gil`. Suggested by Inada Naoki. * Add two sections to "Rejected Ideas": - Why Not Deprecate ``PyDict_GetItem`` in Favor of ``PyDict_FetchItem``? - Why Not Use PEP 683 Immortalization? * Expand on Python build modes
PEP 13: Update current SC members
…2981) After python#2972, when building dirhtml, we need to re-add the initial / for the links to PEPs in the Replaces/Superseded-By/Requires headers.
…ython#2977) * Use #121212 for dark theme bgcolor * Use #1111111 for dark theme bgcolor Co-authored-by: C.A.M. Gerlach <[email protected]> Co-authored-by: C.A.M. Gerlach <[email protected]>
…on#2964) Enforce the use of virtual environments and establish a conventional name for the virtual environment directory. Co-authored-by: Pradyun Gedam <[email protected]> Co-authored-by: Jelle Zijlstra <[email protected]> Co-authored-by: C.A.M. Gerlach <[email protected]> Co-authored-by: Zak Johnson <[email protected]>
pep-9999.rst
Outdated
|
|
||
| This PEP describes a way to record provenance of Python packages installed. | ||
| This record is created by an installer and is available to users in a form of a | ||
| JSON file ``direct_url.json`` in ``.dist-info`` directory. This PEP extends |
There was a problem hiding this comment.
Maybe it would worth to have this renamed:
| JSON file ``direct_url.json`` in ``.dist-info`` directory. This PEP extends | |
| JSON file ``provenance.json`` in ``.dist-info`` directory. This PEP extends |
pep-9999.rst
Outdated
| The JSON document is stating the following entries: | ||
|
|
||
| * ``archive_info.hash`` MUST be present with a value of ``<hash-algorithm>=<expected-hash>``, | ||
| currently supported hash algorithm is only ``sha256``. |
There was a problem hiding this comment.
Could we also add blake2b-256? That is what PEP 458 plans to use after discussion with PyPA folks.
There was a problem hiding this comment.
Sounds reasonable, I'm not sure how the archive_info.hash should look like in such a case as <hash-algorithm> is directly part of its value (maybe comma separated?). This might also open discussion how it should look like in already existing support for direct_url.json.
pep-9999.rst
Outdated
| @@ -0,0 +1,89 @@ | |||
| PEP: 9999 | |||
| Title: Recording provenance of installed packages | |||
There was a problem hiding this comment.
On second thought, maybe we shouldn't call it "provenance", which is a bit overloaded. Maybe "installation reports" is better. Better yet, maybe it could even be a new type of in-toto attestation.
There was a problem hiding this comment.
On second thought, maybe we shouldn't call it "provenance", which is a bit overloaded. Maybe "installation reports" is better.
Installation report can be confused with pip's installation reports.
Better yet, maybe it could even be a new type of in-toto attestation.
Maybe we could add this directly to PEP as an example of usage, beside SBOM already mentioned.
| `PEP-610 <https://peps.python.org/pep-0610/>`_. | ||
|
|
||
|
|
||
| Motivation |
There was a problem hiding this comment.
One important thing from our discussion: what does this proposal give you that installation reports already don't? One may argue that installation reports are too verbose and too specific to the OS/Python versions. However, I think the more significant philosophical difference is that you want these reports/provenance to be produced by default, since most end-users are not going to go through the trouble to explicitly produce them unless compelled. However, even if these reports are produced by default, the problem remains that old applications/containers are going to be missing these reports.
The other issue is whether something higher-level like Hatch might be better suited to producing this information, because then you can associate applications with packages.
fridex
force-pushed
the
pip-provenance
branch
from
a2370bb to
7de13c3
Compare
Co-authored-by: C.A.M. Gerlach <[email protected]>
* Updates based on feedback Adds explanation of handling `bin/` directory, or how we are not trying to replace the existing virtual environments. * Updates grammar based on feedback
fridex
force-pushed
the
pip-provenance
branch
7 times, most recently
from
9218129 to
b040c1d
Compare
Signed-off-by: Fridolin Pokorny <[email protected]>
fridex
force-pushed
the
pip-provenance
branch
from
0c5ba0c to
2a71e6e
Compare
Co-authored-by: C.A.M. Gerlach <[email protected]> Co-authored-by: Hugo van Kemenade <[email protected]>
|
Closing, replaced with #2. |
No description provided.