feat(manager/pip-compile): Support -r dependencies between files

[mbudnek]

Changes

Pip-compile supports including other requirements files via the -r flag. The pip_requirements manager already extracts those flags, but this adds logic to the pip-compile manager to make sure dependent files' lock files get updated when a package is updated in a file that is included via a -r directive.

Note that this does not support including requirements files that aren't managed by pip-compile via -r directives. While doing so won't break anything, the lock files won't get updated when the pip_requirements manager updates a dependency. They will get updated later as part of the next lock file maintenance.

Context

#28050

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[viceice]

otherwise LGTM

[viceice]

new comments

[renovate-release]

🎉 This PR is included in version 37.276.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)
• 37.276.0

Your semantic-release bot 📦🚀

[not7cd]

What if a lock file is duplicated across package files before this operation?

[mbudnek]

Hmm, I suppose that could cause a problem with something like this

graph LR
    a.in --> b.in
    a.in --> c.in
    b.in --> d.in
    c.in --> d.in

In that case a.in's lockFiles would be ["a.txt", "b.txt", "d.txt", "c.txt", "d.txt"] and Renovate would end up running

pip-compile a.in
pip-compile b.in
pip-compile d.in
pip-compile c.in
pip-compile d.in

Where the first instance of pip-compile d.in would likely fail since b.txt and c.txt could ask for different versions of a newly-updated package.

I'll look into fixing that on Monday.