Skip to content

PEP 751: update the post history #4205

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
brettcannon merged 1 commit into from
Jan 16, 2025
Merged

PEP 751: update the post history #4205

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 27 additions & 26 deletions peps/pep-0751.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@ Created: 24-Jul-2024
Post-History:
`25-Jul-2024 <https://discuss.python.org/t/59173>`__
`30-Oct-2024 <https://discuss.python.org/t/69721>`__
`15-Jan-2025 <https://discuss.python.org/t/77293>`__
Replaces: 665

========
Expand Down Expand Up @@ -52,7 +53,7 @@ cost/barrier.

The closest the community has to a standard are pip's `requirements files`_
which all the aforementioned tools either use directly as their file format or
export to (i.e. ``requirements.txt``). Unfortunately the format is not a
export to (i.e. ``requirements.txt``). Unfortunately, the format is not a
standard but is supported by convention. It's also designed very much for pip's
needs, limiting its flexibility and ease of use (e.g., it's a bespoke file
format). Lastly, it is not secure by default (e.g., file hash support is
Expand All @@ -78,7 +79,7 @@ file. It should also lead to faster installs which are much more frequent than
creating a lock file.

The data in the file should be consumable by tools not written in Python. This
allows for e.g., clould hosting providers to write their own tool to perform
allows for e.g., cloud hosting providers to write their own tool to perform
installations in their preferred programming language.

The file format should promote good security defaults. As the format is not
Expand All @@ -105,7 +106,7 @@ A lock file MUST be named :file:`pylock.toml` or match the regular expression
lock files exist. The use of the ``.toml`` file extension is to make syntax
highlighting in editors easier and to reinforce the fact that the file format is
meant to be human-readable. The prefix and suffix of a named file MUST be
lowercase when possible for easy detection and removal,
lowercase when possible, for easy detection and removal,
e.g.:

.. code-block:: Python
Expand All @@ -126,10 +127,10 @@ File Format

The format of the file is TOML_.

Tools SHOULD write their lock files in a consistent way to minmize noise in diff
output. Keys in tables -- including the top-level table -- SHOULD be recorded in
a consistent order. As well, tools SHOULD sort arrays in consistent order. Usage
of inline tables SHOULD also be kept consistent.
Tools SHOULD write their lock files in a consistent way to minimize noise in
diff output. Keys in tables -- including the top-level table -- SHOULD be
recorded in a consistent order. As well, tools SHOULD sort arrays in consistent
order. Usage of inline tables SHOULD also be kept consistent.


``metadata-version``
Expand Down Expand Up @@ -165,7 +166,7 @@ of inline tables SHOULD also be kept consistent.
- **Required?**: no
- **Inspiration**: PDM_, Poetry_, uv_
- Specifies the :ref:`packaging:core-metadata-requires-python` for the minimum
Python version compatibile for any environment supported by the lock file
Python version compatible for any environment supported by the lock file
(i.e. the minimum viable Python version for the lock file).


Expand Down Expand Up @@ -638,12 +639,12 @@ a suggestion):
satisfied.
#. For each package listed in ``[[packages]]``:

#. If ``marker`` is specified, check if it is satisfied; it it isn't,
#. If ``marker`` is specified, check if it is satisfied; if it isn't,
skip to the next package.
#. If ``requires-python`` is specified, check if it is satisfied; an error
MUST be raised if it isn't.
#. Check that no other instance of the package has been slated to be
installed; an error about the ambiguity MUST be raied otherwise.
installed; an error about the ambiguity MUST be raised otherwise.
#. Check that the source of the package is specified appropriately (i.e.
there are not conflicting sources in the package entry);
an error MUST be raised if any issues are found.
Expand Down Expand Up @@ -912,12 +913,12 @@ Other keys
A single hash algorithm for the whole file
==========================================

Earlier versions of this PEP proposed having a single hash algrorithm be
Earlier versions of this PEP proposed having a single hash algorithm be
specified per file instead of any number of algorithms per file. The thinking
was that by specifying a single algorithm it would help with auditing the file
when a specific hash algorithm was mandated for use.

In the end there was some objection to this idea. Typically it centered around
In the end there was some objection to this idea. Typically, it centered around
the cost of rehashing large wheel files (e.g., PyTorch). There was also concern
about making hashing decisions upfront on the installer's behalf which they may
disagree with. In the end it was deemed better to have flexibility and let
Expand Down Expand Up @@ -958,7 +959,7 @@ Locking build requirements for sdists
=====================================

An earlier version of this PEP tried to lock the build requirements for sdists
under a ``packages.build-requires`` key. Unfortunately it confused enough people
under a ``packages.build-requires`` key. Unfortunately, it confused enough people
about how it was expected to operate and there were enough edge case issues to
decide it wasn't worth trying to do in this PEP upfront. Instead, a future PEP
could propose a solution.
Expand Down Expand Up @@ -1173,8 +1174,8 @@ detail as to differentiate from any other entry for the same package in the file
(inspired by uv_).


Including index-hosted attestatons
==================================
Including index-hosted attestations
===================================

:ref:`packaging:index-hosted-attestations` specifies attestation details for
files uploaded to a package index like PyPI. Including some of those details may
Expand All @@ -1189,7 +1190,7 @@ JSON payload as a string, or re-specify some or all of the attestation spec.
Expanding the feature set
-------------------------

This PEP is currenty oriented towards standardizing on something that can
This PEP is currently oriented towards standardizing on something that can
replace a ``requirements.txt`` file that acts as a lock file (e.g., what
`pip-tools`_ produces). But with an expansion of features, the file format may be
able to replace the internal lock file format used by tools like PDM_ and
Expand All @@ -1200,9 +1201,9 @@ for creating a lock file.
Record the requirements for extras of a package
===============================================

A project with a ``pyprojec.toml`` file may define some extras which add
A project with a ``pyproject.toml`` file may define some extras which add
dependencies to install. In the simple case this would just be a matter of
marking an antry in ``[[packages]]`` as only applying when a specific extra is
marking an entry in ``[[packages]]`` as only applying when a specific extra is
requested. Unfortunately the simple case doesn't cover all cases.

Consider the following example where the latest release of NumPy is 2.2.1 and
Expand All @@ -1221,7 +1222,7 @@ own then NumPy 2.2.1 should be recorded in the lock file, but if extra-2 is
specified (either on its own or in conjunction with extra-1), then NumPy 1.26.4
should be recorded.

There are two possible soluutions to this.
There are two possible solutions to this.


A single version across all extras in a single lock file
Expand All @@ -1234,7 +1235,7 @@ you won't be wondering what version of NumPy you will end up with based on what
extras you select.

But this does mean that if you want the version of NumPy to vary across extras
you will need to create separate lock files for the varyious NumPy versions you
you will need to create separate lock files for the various NumPy versions you
want. While not technically an issue, it is ergonomically a bit annoying when
this is necessary. But it's not known how frequently varying package versions
which depend on which extra(s) are chosen occur, and when they do occur do people
Expand All @@ -1246,11 +1247,11 @@ used for. This works thanks to extras being additive, and thus only contributing
more packages.


Support boolean logic for extra selection
Support Boolean logic for extra selection
-----------------------------------------

Another solution to this problem is specifying the conditions under
which a package version applies. This would mean supporting boolean logic
which a package version applies. This would mean supporting Boolean logic
to fully express the conditions under which a package applies.

But historically extras have not been expressed this way. The use of the
Expand All @@ -1267,18 +1268,18 @@ versions apply.

For this to work we would either need to expand the use of the ``extra`` clause
so it can be used in ``packages.marker`` or have an ``extras`` key which
expresses a boolean expression for under which the package should be used. In
expresses a Boolean expression for under which the package should be used. In
both situations the spec around ``extra`` would need to be expanded by this PEP
-- or another PEP before this one is accepted -- to lay out how boolean
-- or another PEP before this one is accepted -- to lay out how Boolean
expressions would work in this case.


Record dependency groups
========================

Dependency groups have the same concerns as extras mentioned above along with
lacking any preexisting clause for use in dependency specifiers. And so
dependency groups have the added issue that to use boolean expressions would
lacking any pre-existing clause for use in dependency specifiers. And so
dependency groups have the added issue that to use Boolean expressions would
require defining a new clause type.


Expand Down
Loading