Unexpected differentiation behavior between minor/major with uv

[RahulGautamSingh]

Discussed in #40166

^{Originally posted by jvllmr December 26, 2025}

How are you running Renovate?

A Mend.io-hosted app

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

42.59.0

Please tell us more about your question or problem

In my project I have a group that contains all pep621 minor and patch updates: https://github.com/jvllmr/flay/blob/917b2e2921b381c9eb340cb939f9ed1b59ae9c50/.github/renovate.json#L49

However, in the following PR pytest in the pyproject.toml receives a major update within a grouped PR: jvllmr/flay#270 (pytest is upgraded from >=8.4.2 to >=9.0.2).
I would expect that there is a separate PR for the pytest major update.

When looking at the log you can see that uv last locked pytest to version 9.0.1 (probably because I generated that lockfile locally). I think renovate considers this a minor update because of this. Could this be changed so that renovate can resolve such situation? That would be great.

Reproduction repo: https://github.com/jvllmr/renovate-discussion-40166

Logs (if relevant)

Logs

{
            "packageName": "pytest",
            "depName": "pytest",
            "datasource": "pypi",
            "depType": "dependency-groups",
            "currentValue": ">=8.4.2",
            "managerData": {
              "depGroup": "test"
            },
            "lockedVersion": "9.0.1",
            "updates": [
              {
                "bucket": "major",
                "newVersion": "9.0.2",
                "newValue": ">=9.0.2",
                "releaseTimestamp": "2025-12-06T21:30:49.000Z",
                "newVersionAgeInDays": 19,
                "newMajor": 9,
                "newMinor": 0,
                "newPatch": 2,
                "updateType": "patch",
                "isBreaking": false,
                "isRange": true,
                "isBump": true,
                "libYears": 0.2555869165398275,
                "branchName": "renovate/python-minor-patch"
              }
            ],
            "versioning": "pep440",
            "warnings": [],
            "sourceUrl": "https://github.com/pytest-dev/pytest",
            "registryUrl": "https://pypi.org/pypi",
            "changelogUrl": "https://docs.pytest.org/en/stable/changelog.html",
            "mostRecentTimestamp": "2025-12-06T21:30:49.000Z",
            "currentVersion": "9.0.1",
            "currentVersionTimestamp": "2025-09-04T14:34:20.000Z",
            "currentVersionAgeInDays": 113,
            "isSingleVersion": false,
            "fixedVersion": "9.0.1"
          },

[RahulGautamSingh]

@secustor Thoughts on this one? I am confused how to decide the bucket for this case where the ranges gets a major bump but locked verison is getting a minor upgrade.

[jvllmr]

As further discussed in #40166 uv can actually lock a dependency with multiple versions depending on the python version constraints.

The current implementation (

renovate/lib/modules/manager/pep621/schema.ts

Lines 218 to 231 in ac0e6ae

	export const UvLockfile = Toml.pipe(
	z.object({
	package: LooseArray(
	z.object({
	name: z.string(),
	version: z.string(),
	}),
	),
	}),
	).transform(({ package: pkg }) =>
	Object.fromEntries(
	pkg.map(({ name, version }): [string, string] => [name, version]),
	),
	);

) squashes all versions so that only the last version in the file remains.
A simple fix would be to use the first entry, but it might be more bulletproof to actively search for the lowest version mentioned in the lockfile.

The PDM processor might also suffer from this because the lockfile extraction works the same way for PDM.
Would a PR for both processors be welcomed?

[jvllmr]

I just checked and PDM only locks the lowest version. So there shouldn't be a change needed for PDM