lockFileMaintenance for uv.lock uses wrong index

[DBS-ST-VIT]

How are you running Renovate?

Self-hosted Renovate

Which platform you running Renovate on?

GitLab (.com or self-hosted)

Which version of Renovate are you using?

42.59.1

Please tell us more about your question or problem

I am having a Python Project, managed by uv.

I am in a company network, where i have to use a custom default pypi index, that i am populating via the environment variable UV_DEFAULT_INDEX to my local uv installation. Lets assume, that this is our local pypi index: https://repo.example.org/artifactory/api/pypi/pypi-remote/simple

For my renovate installation, i configured a global package rule to use this pypi index:

"packageRules": [
   {
     "matchDatasources": ["pypi"],
     "registryUrls": [
       "https://repo.example.org/artifactory/api/pypi/pypi-remote/simple"
     ]
   }
]

Its important to know, that uv writes the source index and package URLs into its lockfile. As a result of that, my local uv installation is injecting also my local pypi index into my uv.lock file.

But if i renovate this project, i get a merge request with e.g. this change in the uv.lock file:

[[package]]
name = "attrs"
version = "25.4.0"
-source = { registry = "https://repo.example.org/artifactory/api/pypi/pypi-remote/simple" }
-sdist = { url = "https://repo.example.org/artifactory/api/pypi/pypi-remote/packages/packages/6b/5c/685e6633917e101e5dcb62b9dd76946cbb57c26e133bae9e0cd36033c0a9/attrs-25.4.0.tar.gz", hash = "sha256:16d5969b87f0859ef33a48b35d55ac1be6e42ae49d5e853b597db70c35c57e11" }
+source = { registry = "https://pypi.org/simple" }
+sdist = { url = "https://files.pythonhosted.org/packages/6b/5c/685e6633917e101e5dcb62b9dd76946cbb57c26e133bae9e0cd36033c0a9/attrs-25.4.0.tar.gz", hash = "sha256:16d5969b87f0859ef33a48b35d55ac1be6e42ae49d5e853b597db70c35c57e11", size = 934251, upload-time = "2025-10-06T13:54:44.725Z" }
wheels = [
-    { url = "https://repo.example.org/artifactory/api/pypi/pypi-remote/packages/packages/3a/2a/7cc015f5b9f5db42b7d48157e23356022889fc354a2813c15934b7cb5c0e/attrs-25.4.0-py3-none-any.whl", hash = "sha256:adcf7e2a1fb3b36ac48d97835bb6d8ade15b8dcce26aba8bf1d14847b57a3373" },
+    { url = "https://files.pythonhosted.org/packages/3a/2a/7cc015f5b9f5db42b7d48157e23356022889fc354a2813c15934b7cb5c0e/attrs-25.4.0-py3-none-any.whl", hash = "sha256:adcf7e2a1fb3b36ac48d97835bb6d8ade15b8dcce26aba8bf1d14847b57a3373", size = 67615, upload-time = "2025-10-06T13:54:43.17Z" },
]

(This is happening to all dependencies in the uv.lock file)

So it seems like renovate is just ignoring the custom index from the packageRules configuration on lockFileMaintenance actions.

I just had a look into the code and found the following:

• https://github.com/renovatebot/renovate/blob/main/lib/modules/manager/pep621/processors/uv.ts#L27
• https://github.com/renovatebot/renovate/blob/main/lib/modules/manager/pep621/processors/uv.ts#L208

Renovate just runs uv lock --upgrade and doesn't pass the custom pypi index via e.g. --index-url or something similar.

So whats the problem? At the one hand, this is a ping pong in the commit history, as my local uv installation and renovate are permanently exchanging the URLs in the lockfile. On the other hand, and thats the real problem: If the uv workspace is installed by executing uv sync, files are downloaded from the URLs that are found in the lockfile, which leads us to the problem, that this command is frequently failing, as uv cannot access the internet with the official pypi index, that was configured by renovate.

I already tried to set the mentioned environment variable UV_DEFAULT_INDEX with my local pypi index for renovate, but it seems that it is not passed to the uv subprocess.

Logs (if relevant)

No response

[DBS-ST-VIT]

So a colleague pointed out, that my assumption of renovate's behavior is correct, and that i need to pass the UV_DEFAULT_INDEX via customEnvVariables in the renovate configuration. I added that to our configuration and now, everything works as expected.

I will keep this disucssion open, as i personally think, that renovates default behavior is not really the one, that i expected. I am interested in the opinion of renovate's maintainers about this.

[benjaminknauer]

Same issue here. This is very counter-intuitive.

Even with Renovate configured to use only our Nexus PyPI proxy, updating uv.lock causes Renovate to run uv lock in a way that falls back to the global default (pypi.org) and rewrites the lockfile accordingly.

For environments where public PyPI must never be used, this is a serious problem and easy to miss in PR review.

Expectation from a user perspective:
If Renovate is configured with a custom Python registry, it should never resolve or lock against pypi.org unless explicitly configured.

At minimum, Renovate should either propagate the configured index to uv or fail instead of silently falling back.