Norbert Szulc

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

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

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...

I don't know what is untested based on coverage report ``` Run pnpm nyc report -t ./coverage/nyc --skip-full -r text -r text-summary ---------------------------------------|---------|----------|---------|---------|------------------- File | % Stmts | % Branch...

> One in particular is packageRules. Today matchPackage* actually functions on the depName field and not the packageName. Is this statement still true?

Is there a way to make this change non-breaking? Would this involve some sort of normalization of the configuration itself?

There are several problems and they mainly comes down to comparasion logic. 1. vulnerability alerts are case sensitive: for example `Pillow` is returned with its non-normalized name, but it may...

As per documentation. There are more valid names that can lead to rules not matching. https://packaging.python.org/en/latest/specifications/name-normalization/ This means that the following names are all equivalent: - friendly-bard (normalized form) -...

What do you mean by that? We as a manager? Where such logic should exist? Still the simplest way is to compare normalized names. If I understand correctly `packageName` is...

I would prefer `normalizePythonPackageName` as this is general spec, as per doc linked earlier. How this issue relates to #28551? It's desirable to include this PR with another breaking change?...