Commit changes to workspace member TOML files

[crabbit-git]

What are you trying to accomplish?

Fix issue #14937, at least to the extent that CI pipelines containing uv sync --locked no longer fail when workspace members (as opposed to top-level pyproject.toml) have their dependencies updated by Dependabot.

The problem appears to be that the implementation of PR #14627 achieves its dependency updates for workspace members by editing the member pyproject.toml files but not actually committing them because their support_file is true. This is flawed because it results in the requires-dist metadata inside uv.lock being updated to match the edited requirements imposed by the TOML edits, which creates a conflict between the actually committed TOML and uv.lock, causing any uv sync --locked in CI pipelines to fail.

There is another thing that might be wrong which affects the repo I noticed this happening in: as I said on the issue, I believe the TOML shouldn't even be getting touched for these kinds of updates when the versioning strategy is set to "bump versions when necessary", as opposed to the default "bump versions". It should therefore be updating the TOML files relatively infrequently. Instead, it seems that it is falling back to the default strategy, causing it to update the TOML (even though, due to the aforementioned bug, it never commits said TOML) every time it updates something in the lock file. This may be out of scope for the PR and may not even reside in this repo so I'm not going to try to address it here for the time being; the much more urgent problem is the CI failures caused by this mismatch between different parts of the lock file and between the lock file and the TOML.

How will you know you've accomplished your goal?

I manually replicated the approach taken by Dependabot against the uv repo that I noticed the problem in to verify that uv sync --locked passes while the temp-edited inner .toml file exists but fails once it is purged (simulating Dependabot's flow failing to commit it due to support_file = true).

Unfortunately, it appears that I will be unable to run the kind of testing I would prefer, because that would require x86 architecture and the only machine I currently have on hand is ARM. I'm therefore having to trust a mix of CI and manual sanity checking to confirm that this has worked and does not have unintended impact. If anybody has access to x86 and is able and willing to run the testing on their end (ideally including running the script to dry-run it on an example repo), I would be very grateful for the assist.

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.

[crabbit-git]

This passed all CI when I rebased and pushed it earlier, including the build stage. Somebody re-triggered it after that and the build stage failed with a "suspended account" error. Rebasing again to see if it works this time. EDIT: passed again.

[mpol1t]

@crabbit-git I tested this on an x86_64 machine locally and also checked the GitHub Actions coverage for the same commit. For 5eb5a762aae2ca71b90719ce7b8720f840ef04c9, the ci (uv, uv, uv) job passed on GitHub’s standard ubuntu-latest x64 runner, and the uv smoke e2e job passed as well. I also ran the relevant uv lock-file updater spec locally against this PR’s changes: bundle exec rspec spec/dependabot/uv/file_updater/lock_file_updater_spec.rb, which completed with 76 examples, 0 failures. The separate ARM64 Build workflow also succeeded, so this looks good from both GitHub-hosted x64 CI and local x86_64 testing.