📋 Dependabot research: Continue manual dependency management until uv support

[matrixise]

Executive Summary

After researching Dependabot integration with our current uv-based dependency management workflow, we've decided to continue with manual dependency management for now and revisit when Dependabot adds native uv support.

Current Dependency Workflow

Our project uses a multi-file requirements approach:

• Source files: requirements/main.in, requirements/dev.in, requirements/production.in (dependencies without pinned versions)
• Compiled files: requirements/main.txt, requirements/dev.txt, requirements/production.txt (auto-generated with exact pinned versions via uv pip compile)

Existing tools that work well:

• task dependencies:upgrade - Update all dependencies
• task dependencies:security - Vulnerability scanning with pip-audit
• Dependabot security alerts - Already active (GitHub default feature)

Research Findings

1. uv is NOT natively supported by Dependabot (December 2024)

Despite strong community interest:

• Support python uv as pip-compile compatible replacement (185+ 👍)
• Support updating uv.lock (572+ 👍)
• See this interesting comment: GitHub's response on uv.lock support status

2. Version Pinning Problem

• Our .in files specify dependencies without exact versions (e.g., Django not Django==6.0)
• Only .txt files have exact pinned versions (auto-generated)
• Dependabot can't effectively monitor .in files without version constraints
• Monitoring .txt files would create PRs for auto-generated files (breaks our workflow)

3. Current Workaround Requires Major Migration

The recommended approach requires:

• Migrating to pyproject.toml for dependency specification
• GitHub Action to auto-regenerate lockfiles when Dependabot updates pyproject.toml
• Significant project restructuring

See: Keep uv.lock file up-to-date with Dependabot updates

4. pip-compile Support Has Limitations

While Dependabot supports pip-compile, there are known issues:

• Formatting changes between pip-tools versions
• Transitive dependency conflicts

Decision: Continue Manual Workflow

Reasons:

1. ✅ uv is not yet supported natively by Dependabot
2. ✅ Current workflow with task dependencies:* commands works well
3. ✅ Security alerts are already active (most critical feature)
4. ✅ Migration to pyproject.toml would be a significant change
5. ✅ Can revisit when Dependabot adds native uv support

What We Keep Monitoring

• Dependabot security alerts (already active)
• Manual updates via task dependencies:upgrade
• Vulnerability scanning via task dependencies:security
• Progress on the uv support issues linked above

When to Revisit

We'll reconsider Dependabot version updates when:

• Native uv support is added to Dependabot, OR
• We migrate to pyproject.toml for other reasons

References

• Support python uv as pip-compile compatible replacement
• Support updating uv.lock
  • Interesting comment on uv.lock support status
• Keep uv.lock file up-to-date with Dependabot updates
• Dependabot pip-compile support
• handling multiple requirements.txt like files

[ulgens]

Hey @matrixise, is there a reason to focus on Dependabot and not the alternatives?

[matrixise]

Hi @ulgens, thanks for your question!

We're already using Dependabot for security alerts, and I prefer to stick with it rather than switching to an alternative that might be abandoned in a few years. I'm currently cleaning up the repository to make it easier for others to take over in the future, so stability and longevity of the tools we use is important.

What alternatives were you thinking of?

[ulgens]

We're already using Dependabot for security alerts

The last time I checked, Dependabot's security fix PRs for pyproject using repos were broken (marking the security issue as resolved without updating the lock file). I don't trust dependabot for security alerts and wouldn't recommend doing so.

I prefer to stick with it rather than switching to an alternative that might be abandoned in a few years.

My alternative here was Renovatebot, which has been around for ~10 years and is going strong. It may be even older than Dependabot, and it's definitely working better with modern tooling.

[matrixise]

Hi @ulgens,

Thank you for bringing up Renovatebot! I took your suggestion seriously and did some research with Claude's help. You're absolutely right - Renovatebot looks very promising for our use case.

Key findings:

1. Dependabot limitations: Your concern about Dependabot's broken security fix PRs for pyproject.toml repos is valid and concerning.

2. Renovatebot advantages:

   • Native support for uv (via PEP 621 manager with uv.lock files)
   • Excellent support for pip-compile workflows (our current .in/.txt setup)
   • Been around for ~10 years and actively maintained
   • Free for open source projects via the GitHub App
   • Better API rate limits (15,000/h vs 5,000/h)

3. Zero-cost, zero-infrastructure: The Mend Renovate GitHub App is completely free for public repos with no setup beyond a simple config file.

I'm going to create a separate issue to track Renovatebot integration since it's a different approach than the manual workflow we discussed here. This will let us explore both options properly.

Thanks again for the suggestion! 🙏

[ulgens]

@matrixise I'm happy that you found it useful. Let me know if there is anything I can help with.

Meanwhile, I have this small repo to store and share what I consider "sane defaults" for Renovate. Feel free to use or copy from that repo if you think it's useful 🌸

[ulgens]

Btw, is "Key findings" part of your comment Claude output?

[matrixise]

Yep, why?

[ulgens]

Nothing important. I didn't understand it the first time I read, then it clicked, and wanted to be sure. Thanks.