Python
/
uv
mirror of https://github.com/astral-sh/uv
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Minor internal README enhancement for Markdown list in PEP440 (#13880) 

- Define all list elements using `-`: it used to be a mix of `*` and
`-`. `-` is what Prettier linter formats it to by default.
- Removed unnecessary blank line between 2 list elements. Other elements
were stitched together without blank lines in between.
- Only the first list element started in sentence case (capital letter
first) - I made all start like so.
This commit is contained in:
Yury Fedotov 2025-06-06 09:45:37 -04:00 committed by GitHub
parent bf96c60e3e
commit 8a88ab2c70
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 7 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
crates/uv-pep440/Readme.md
View File

@ -26,20 +26,19 @@ PEP 440 has a lot of unintuitive features, including:
- An epoch that you can prefix the version with, e.g., `1!1.2.3`. Lower epoch always means lower - An epoch that you can prefix the version with, e.g., `1!1.2.3`. Lower epoch always means lower
version (`1.0 <=2!0.1`) version (`1.0 <=2!0.1`)
- Post versions, which can be attached to both stable releases and pre-releases
* post versions, which can be attached to both stable releases and pre-releases - Dev versions, which can be attached to sbpth table releases and pre-releases. When attached to a
* dev versions, which can be attached to sbpth table releases and pre-releases. When attached to a
pre-release the dev version is ordered just below the normal pre-release, however when attached to pre-release the dev version is ordered just below the normal pre-release, however when attached to
a stable version, the dev version is sorted before a pre-releases a stable version, the dev version is sorted before a pre-releases
* pre-release handling is a mess: "Pre-releases of any kind, including developmental releases, are - Pre-release handling is a mess: "Pre-releases of any kind, including developmental releases, are
implicitly excluded from all version specifiers, unless they are already present on the system, implicitly excluded from all version specifiers, unless they are already present on the system,
explicitly requested by the user, or if the only available version that satisfies the version explicitly requested by the user, or if the only available version that satisfies the version
specifier is a pre-release.". This means that we can't say whether a specifier matches without specifier is a pre-release.". This means that we can't say whether a specifier matches without
also looking at the environment also looking at the environment
* pre-release vs. pre-release incl. dev is fuzzy - Pre-release vs. pre-release incl. dev is fuzzy
* local versions on top of all the others, which are added with a + and have implicitly typed string - Local versions on top of all the others, which are added with a + and have implicitly typed string
and number segments and number segments
* no semver-caret (`^`), but a pseudo-semver tilde (`~=`) - No semver-caret (`^`), but a pseudo-semver tilde (`~=`)
* ordering contradicts matching: We have, e.g., `1.0+local > 1.0` when sorting, but `==1.0` matches - Ordering contradicts matching: We have, e.g., `1.0+local > 1.0` when sorting, but `==1.0` matches
`1.0+local`. While the ordering of versions itself is a total order the version matching needs to `1.0+local`. While the ordering of versions itself is a total order the version matching needs to
catch all sorts of special cases catch all sorts of special cases