Parse calls packageurl.FromString, which runs Normalize() and applies per-type rules (lowercasing pypi names, composer namespaces, etc). New and MakePURL call packageurl.NewPackageURL directly and skip that step, so the two paths disagree:
purl.Parse("pkg:pypi/Django").String() // "pkg:pypi/django"
purl.MakePURLString("pypi", "Django", "") // "pkg:pypi/Django"This bit git-pkgs/proxy#197: config keys were normalized via Parse but runtime lookup keys came from MakePURLString, so overrides for scoped npm packages and mixed-case pypi packages silently failed to match.
Calling p.Normalize() inside New before returning would make construction and parsing agree. It changes output for existing callers that persist these strings (git-pkgs/proxy#207 tracks the migration on that side), so probably wants a minor version bump and a changelog note.
Parsecallspackageurl.FromString, which runsNormalize()and applies per-type rules (lowercasing pypi names, composer namespaces, etc).NewandMakePURLcallpackageurl.NewPackageURLdirectly and skip that step, so the two paths disagree:This bit git-pkgs/proxy#197: config keys were normalized via
Parsebut runtime lookup keys came fromMakePURLString, so overrides for scoped npm packages and mixed-case pypi packages silently failed to match.Calling
p.Normalize()insideNewbefore returning would make construction and parsing agree. It changes output for existing callers that persist these strings (git-pkgs/proxy#207 tracks the migration on that side), so probably wants a minor version bump and a changelog note.