From e6ed1ed1e0df6262fd9964d48e301c7a7564c3e1 Mon Sep 17 00:00:00 2001 From: Paul Moore Date: Thu, 20 Mar 2025 12:21:33 +0000 Subject: [PATCH] Some minor copy edits for PEP 751 --- peps/pep-0751.rst | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/peps/pep-0751.rst b/peps/pep-0751.rst index 8115006537a..2f12b113cfc 100644 --- a/peps/pep-0751.rst +++ b/peps/pep-0751.rst @@ -235,7 +235,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent. file). - Tools supporting dependency groups MUST also support extras. - Tools SHOULD explicitly set this key to an empty array to signal that the - inputs used to generate the lock file had no extras (e.g. a ``pyproject.toml`` + inputs used to generate the lock file had no dependency groups (e.g. a ``pyproject.toml`` file had no ``[dependency-groups]`` table), signalling that the lock file is, in effect, multi-use even if it only looks to be single-use. @@ -361,6 +361,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent. contains. - Tools MAY choose to not support version control systems, both from a locking and/or installation perspective. +- Tools MAY choose to only support a subset of the available VCS types. - Tools SHOULD provide a way for users to opt in/out of using version control systems. - Installation from a version control system is considered originating from a @@ -1094,7 +1095,7 @@ use-cases based on extras and dependency groups. It is up to the tool(s) you use that decide whether multi-use lock files are possible. All tools dealing with lock files at least support single-use lock files. Neither type of lock file is better or worse than the other, it just changes how much can be written down -in a single file (which can influence how manageable). +in a single file. Lock files that follow this PEP can be installed by any installer that implements the specification. This allows users of a lock file to perform an @@ -1269,7 +1270,7 @@ Recording the creation date of the lock file ============================================ To know how potentially stale the lock file was, an earlier proposal suggested -recording the creation date of the lock file. But for some same merge conflict +recording the creation date of the lock file. But for the same merge conflict reasons as storing the hash of the file contents, this idea was dropped. @@ -1315,7 +1316,7 @@ Drop recording the package version ================================== The package version is optional since it can only be reliably recorded when an -sdist of wheel file is used. And since both sources record the version in file +sdist or wheel file is used. And since both sources record the version in file names it is technically redundant. But in discussions it was decided the version number is useful for auditing