* refactor(versioning/poetry): accept PEP 440 specifiers instead of a lookup special case
`filterVersions()` carried a poetry-shaped branch: when `allowedVersions` was no
valid poetry range but a valid PEP 440 specifier, it matched releases with the
pep440 versioning instead. Poetry accepts PEP 440 specifiers, so the poetry
versioning is where that belongs: `isValid()` falls back to `pep440.isValid()`
and `matches()` to `pep440.matches()` for a range poetry's own syntax cannot
express, and the three versioning imports leave `filter.ts`.
The `config.versioning !== npmVersioning.id` guard on the semver fallback is
dropped as well: npm's `isValid()` is `validRange()` over a normalisation which
only rewrites x-ranges, so it accepts everything `semver.validRange()` accepts
(checked over 163k generated ranges) and the fallback was already unreachable
for npm versioning.
Behaviour changes:
- Poetry `isValid()` now accepts PEP 440 specifiers such as `!=1.2.3` or
`>=2.6, !=3.0.*, <4`, which it used to reject. The poetry manager is
unaffected, because it tests pep440 before poetry when picking a versioning.
- Poetry `matches()` now answers those ranges through pep440 everywhere, not
only for `allowedVersions`.
- For poetry versioning, an `allowedVersions` which is an invalid poetry range
but valid as both a semver range and a PEP 440 specifier is now matched by
pep440 rather than semver, because the pep440 fallback moved ahead of the
semver one.
* fix(versioning/poetry): route every PEP 440-only range to pep440
CI caught `python` versioning's `isLessThanRange('1.9.0', '== 2.7.*')` throwing
`Invalid comparator: ==`: since poetry `isValid()` accepts PEP 440 specifiers,
the python wrapper dispatched that range to poetry, whose npm-based
`isLessThanRange()` cannot parse it. Only `matches()` had the pep440 fallback.
`isLessThanRange()`, `getSatisfyingVersion()`, `minSatisfyingVersion()` and
`getNewValue()` now delegate to pep440 for ranges poetry's own syntax cannot
express, and `subset()` answers `undefined` for them instead of throwing.
The `python` versioning's `poetry.isValid(range) ? poetry : pep440` ternaries
became dead code (poetry now answers every valid range itself, and both modules
receive the same invalid ranges), so the module is `{ ...poetry, isBreaking }`.
The poetry spec also gains rows for three branches nothing covered before: an
unparsable candidate in `getSatisfyingVersion()` / `minSatisfyingVersion()`,
and `getNewValue()` with the `*` range, for which npm's implementation returns
`null`.
* test(versioning/poetry): keep the new spec rows clear of main's coverage rows
main's #46252 appended rows to the same minSatisfyingVersion, getSatisfyingVersion and getNewValue tables, which made the stacked PR conflict with main. Those rows are adopted verbatim at the table ends and the pep440 rows move into the middle of each table, so both sides merge cleanly.
Refactors `getNewValue` logic to replace it with an optional
`getPinnedValue()` where rangeStrategy=pin. This way each versioning
module doesn't need to add and test extensive "pin" logic.
This should not be breaking, but out of an abundance of caution, we'll
mark it as such.
Sebastian Poxhofer