fix(manager/pip-compile): Workaround for no lockFiles

[not7cd]

Changes

#26858 introduced a regression. Because higher functions don't pass a lock files associated with a given package file, and UpdateArtifactsConfig has lock files from a first package file, lock file maintenance will ignore the rest. The workaround used available packageFiles data associated to manager, and patched config passed to updateArtifacts

Context

@mbudnek has found this issue

Documentation (please check one with an [x])

• [ ] I have updated the documentation, or
• [x] 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
• [x] No unit tests but ran on a real repository, or
• [ ] Both unit tests + ran on a real repository

[not7cd]

Hopefully it will ignore infered lock files if they don't exist

[not7cd]

This workaround may break more things. Attempt 2 will require mayor refactor in tests and hack some data in managerData

[not7cd]

Tested on a real repo https://github.com/icetek-lab/renovate-case2/pull/8

[not7cd]

I still don't know what should I expect at the input of updateArtifacts. Current interface with package file name/path, it's contents and config is lacking. config seems to be this catch all bag of data, but seems fragile.

This whole workaround can be taken away from get-updated and into pip-compile. Because it looks like only pip-compile became dependent on config.lockFiles.

But putting some plumbing before updateArtifacts can enable its interface change before refactoring get-updated and further methods.

[mbudnek]

@rarkins @viceice Any chance of getting this merged? This issue is currently blocking me from rolling renovate out to most of my team's python-based projects.

[renovate-release]

:tada: This PR is included in version 37.214.5 :tada:

The release is available on:

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

Your semantic-release bot :package::rocket: