`parse_wheel_filename` can return a project name that fails `is_normalized_name`

[sbidoul]

Currently, is_normalized_name only accepts ascii characters:

packaging/src/packaging/utils.py

Line 64 in b62954b

_normalized_regex = re.compile(r"[a-z0-9]+(?:-[a-z0-9]+)*", re.ASCII)

On the other hand, the wheel specification explicitly says The archive filename is Unicode. It will be some time before the tools are updated to support non-ASCII filenames, but they are supported in this specification.

parse_wheel_filename, following that spec, accepts unicode alphanumeric characters:

packaging/src/packaging/utils.py

Line 69 in b62954b

_wheel_name_regex = re.compile(r"^[\w._]+\Z", re.UNICODE)

However, while parse_wheel_filename is typed to return NormalizedName and it uses canonicalize_name, it can return names that fail is_normalized_name.

Example:

>>> from packaging.utils import is_normalized_name, canonicalize_name, parse_wheel_filename
>>> name, _, _, _ = parse_wheel_filename("foo_bÁr-1.0-py3-none-any.whl")
>>> name
'foo-bár'
>>> is_normalized_name(name)
False

Should is_normalized_name accept non-ascii alphanumeric characters? Or something else?

[sbidoul]

I think this discussion also extends to parse_sdist_filename.

[saisharan0103]

parse_wheel_filename can accept foo_bÁr-1.0-py3-none-any.whl, canonicalize it to foo-bár, and still return it as NormalizedName even though is_normalized_name rejects it. For a PR, I would start by preserving the NormalizedName invariant and rejecting non-ASCII wheel distribution names before returning. The regression test should cover that filename and assert the parser raises instead of returning a name that fails its own normalization predicate.