mirror of
https://github.com/renovatebot/renovate.git
synced 2026-10-25 23:11:31 +00:00
Sebastian Poxhofer
c94897829c
* 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.
22 lines
647 B
TypeScript
22 lines
647 B
TypeScript
import { api as poetry } from '../poetry/index.ts';
|
|
import type { VersioningApi } from '../types.ts';
|
|
|
|
export const id = 'python';
|
|
export const displayName = 'Python';
|
|
export const urls = [];
|
|
export const supportsRanges = false;
|
|
|
|
export function isBreaking(current: string, version: string): boolean {
|
|
const currentMajor = poetry.getMajor(current);
|
|
const currentMinor = poetry.getMinor(current);
|
|
const newMajor = poetry.getMajor(version);
|
|
const newMinor = poetry.getMinor(version);
|
|
return !(currentMajor === newMajor && currentMinor === newMinor);
|
|
}
|
|
|
|
export const api: VersioningApi = {
|
|
...poetry,
|
|
isBreaking,
|
|
};
|
|
export default api;
|