Support updating uv.lock

[edgarrmondragon]

Is there an existing issue for this?

• I have searched the existing issues

Feature description

Now that uv has a lockfile, it would be nice if dependabot supported making updates to pyproject.toml and/or uv.lock using uv.

Related:

• Support python uv as pip-compile compatible replacement #10039
• Support uv compiled requirements files #10040
• Python: Support PEP 735 [dependency-groups] in pyproject.toml #10847
• Python: Support inline script metadata (PEP 723) #11946

[dvf]

Hell ye 🙌

[danieltalsky]

We're stuck with Dependabot due to corporate reasons and we'd love Dependabot support for uv.lock files as soon as possible.

[EdmundGoodman]

This has also blocked us, so +1 for prioritising this.

As a stopgap in the meantime, I've hacked together a small GitHub Actions workflow which provides fairly similar functionality to unblock our project whilst we wait. A small demo is available here https://github.com/EdmundGoodman/update-bot if it is helpful to anyone else.

It slightly differs from dependabot in that it makes a PR on a cron schedule if any dependency can be updated rather than whenever a security vulnerability is found, but is good enough for us for now. It differs from other workflows I've seen in this thread, as it PRs rather than just directly committing to main which could break things.

[inoa-jboliveira]

Hi everyone, according to Astral, uv is used to download over 200M packages from pypi everyday.

I verified this info via BigQuery and it is true as yesterday there were 219M downloads from pypi out of 1950M downloads. A total of 11% of all requests made.

Another tool that dependabot supports is poetry and it only comprises <4% of all requests on the same date.

Please see that uv is a extremely relevant project that would be incredibly appreciated if dependabot supports. I don't know if there is any maintainer reading this, but please check the stats.

Query:

SELECT
    COUNT(IF(details.installer.name = 'uv', 1, NULL)) AS uv_downloads,
    COUNT(*) AS total_downloads,
    SAFE_DIVIDE(
        COUNT(IF(details.installer.name = 'uv', 1, NULL)),
        COUNT(*)
    ) * 100 AS percentage
FROM
  `bigquery-public-data.pypi.file_downloads` WHERE TIMESTAMP_TRUNC(timestamp, DAY) = TIMESTAMP("2024-11-06")

[win845]

As this is taking a while, I have created a github action as a temporary workaround which mimics pip-complile for dependabot.
The push.yml workflow is calling uv-sync.sh to generate a requirements.txt with pip-compile comment for dependabot to pick up

If the previous commit author is dependabot it will add the new updated requirements.txt as constraint to pyproject.toml and run uv lock to update the lockfile.

It exports uv.lock to requirements.txt and adds the pip-compile comment. (also if you forgot to do it yourself)
Finally new uv.lock and requirements.txt are pushed as extra commit.

there is a demo https://github.com/win845/uv-light which has couple of outdated major and minor dependencies, causing dependabot to make pull requests.

NOTE: the extra commit in a github action will not retrigger the workflow again by convention

[sebastian-correa]

Can someone from the Dependabot team comment on if this is on their backlog and with what priority? I agree with @inoa-jboliveira that uv is picking up a lot of steam and not having Dependabot support is hindering its adoption in a couple projects I work on 😢.

[samuelhwilliams]

We switched to another tool for dependency management so that we could start using uv 🤷‍♂️ Just one datapoint of the effects of slow adoption here, but there are alternatives out there.

[bosd]

@samuelhwilliams What is the alternative with uv support you are using?

[chris48s]

@bosd Renovate's pep621 manager supports updating uv.lock https://docs.renovatebot.com/modules/manager/pep621/

[samuelhwilliams]

^ yep, that

[zanieb]

We've just released uv 0.6.7 with the aforementioned validation fix (astral-sh/uv#12235). I've preemptively written an issue summarizing my understanding of the problem: astral-sh/uv#12254

I'd like to reiterate that the uv team continues to be excited about Dependabot support for uv. If you're working on a fix for this issue in Dependabot, feel free to ping me for review — I can loop in relevant stakeholders from Astral.

[ulgens]

I created an update PR for 0.6.7 version, can be found at #11844

[RJPercival]

FYI: Looks like the list of package-ecosystem values on https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#package-ecosystem- still needs uv added.

[edgarrmondragon]

There still seem to be some TOML issues, strangely only affecting some dependencies.

Details

updater | 2025/03/19 15:32:39 ERROR <job_983290999> Error processing setuptools (NoMethodError)
2025/03/19 15:32:39 ERROR <job_983290999> undefined method `keys' for an instance of String
updater | 2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/toml-rb-4.0.0/lib/toml-rb/dumper.rb:32:in `sort_pairs'
2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/toml-rb-4.0.0/lib/toml-rb/dumper.rb:77:in `block (2 levels) in dump_table_array_pairs'
2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/toml-rb-4.0.0/lib/toml-rb/dumper.rb:75:in `each'
2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/toml-rb-4.0.0/lib/toml-rb/dumper.rb:75:in `block in dump_table_array_pairs'
updater | 2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/toml-rb-4.0.0/lib/toml-rb/dumper.rb:71:in `each'
2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/toml-rb-4.0.0/lib/toml-rb/dumper.rb:71:in `dump_table_array_pairs'
2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/toml-rb-4.0.0/lib/toml-rb/dumper.rb:52:in `dump_pairs'
2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/toml-rb-4.0.0/lib/toml-rb/dumper.rb:24:in `visit'
2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/toml-rb-4.0.0/lib/toml-rb/dumper.rb:66:in `block in dump_nested_pairs'
2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/toml-rb-4.0.0/lib/toml-rb/dumper.rb:63:in `each'
2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/toml-rb-4.0.0/lib/toml-rb/dumper.rb:63:in `dump_nested_pairs'
updater | 2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/toml-rb-4.0.0/lib/toml-rb/dumper.rb:51:in `dump_pairs'
2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/toml-rb-4.0.0/lib/toml-rb/dumper.rb:24:in `visit'
updater | 2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/toml-rb-4.0.0/lib/toml-rb/dumper.rb:12:in `initialize'
2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/toml-rb-4.0.0/lib/toml-rb.rb:97:in `new'
2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/toml-rb-4.0.0/lib/toml-rb.rb:97:in `dump'
2025/03/19 15:32:39 ERROR <job_983290999> /home/dependabot/uv/lib/dependabot/uv/file_updater/pyproject_preparer.rb:37:in `freeze_top_level_dependencies_except'

apparently happening in

dependabot-core/uv/lib/dependabot/uv/file_updater/pyproject_preparer.rb

Line 37 in 0d36004

TomlRB.dump(pyproject_object)

For reference:

• https://github.com/meltano/meltano/actions/runs/13950441068/job/39048269473
• https://github.com/meltano/meltano/blob/main/pyproject.toml

[gegoune]

With recent changes I am no longer getting #10478 (comment), which is great, thanks!

But all my PR are removing extras now, as per #10478 (comment).
Just reinstating it here in case it got lost between multiple reports since.

[henriquegemignani]

I'm getting some build errors related to setuptools-scm not being able to detect the correct version: https://github.com/randovania/randovania/actions/runs/13977902638/job/39136100713

(These usually happens with my project when you use a shallow clone or a fork without tags.)

[bossenti]

For this run the changes look now pretty good, but dependabot adapts the requires_dist in package.metadata contrary to the definition in pyproject.toml

[therefromhere]

@urschrei can you please file a bug? cc: @markhallen

@abdulapopoola I've logged this as

• uv dependabot removes extras #11896

[ShannonSD-h]

This is tangential, but does this update include support for dependabot's dependency graph?
I see the dependency graph supported package ecosystems still do not include UV: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/dependency-graph-supported-package-ecosystems#supported-package-ecosystems

[willmurphyscode]

I'm getting some build errors related to setuptools-scm not being able to detect the correct version: https://github.com/randovania/randovania/actions/runs/13977902638/job/39136100713

(These usually happens with my project when you use a shallow clone or a fork without tags.)

I think I'm seeing a similar problem, except uv-dynamic-versioning and hatch: https://github.com/anchore/vunnel/actions/runs/14046372968/job/39327971166#step:3:478 (probably also due to a source code download that doesn't have git tags). This seems to prevent dependency updates from happening at all since the build can't set the version based on git tags and exits unsuccessfully.

[woodruffw]

For xref purposes: I've opened #11946 as a related issue for PEP 723, i.e. "inline script metadata," which is another common way people use uv to manage dependencies. It's slightly different from this issue in that it concerns individual source files rather than uv.lock files, but might be of interest to many of the same people in this thread.

[bct]

Does this work with UV workspaces?

I'm seeing failures like:

`my-lib` references a workspace in `tool.uv.sources` (e.g., `my-lib = {workspace = true }`), but is not a workspace member

This seems to be because dependabot copies pyproject.toml and uv.lock to a temporary directory, but pyproject.toml references workspace paths that don't exist within the temporary directory.

[codl]

For this run the changes look now pretty good, but dependabot adapts the requires_dist in package.metadata contrary to the definition in pyproject.toml

Noticing the same issue here codl/mastodon-apod@a9d8866. It gets overwritten by uv on the first sync or lock but it generates a lot of unnecessary diff. uv sync --locked fails on such uv.lock files generated by dependabot

[rissson]

It also looks like the uv manager does not have the same behaviour as the poetry one when it comes to updating the lockfile only. For instance, we have a bunch or dependencies that are not locked to a specific version in our pyproject.toml. With poetry, the poetry.lock would be updated by dependabot to update those, and it only changed the lock file. This also worked for indirect deps, which doesn't seem to be happening for uv.