PyPI does not honor package name from author in some cases

[warsaw]

Describe the bug
PyPI's UI does not honor the package name I specify in my pyproject.toml file. This leads to confusion and incorrect (or at least unintentional) installation instructions on the PyPI front page of the project.

Take for example flufl.i18n. I clearly call the project that in its pyproject.toml file. That's the name I want to advertise the package as, and this intentional -- and legal -- so PyPI should honor that, even if the packaging tools normalize the upload file name. But this doesn't happen, as this screenshot illustrates.

The URL is also normalized: https://pypi.org/project/flufl-i18n/.

Expected behavior
I would expect PyPI at least to display flufl.i18n 5.0.1 on the project page, and provide a pip install command as pip install flufl.i18n. If it doesn't do this, it directly conflicts with my intentional choices and my own documentation.

I think the URL should also be non-normalized, but I'm a little less concerned about that.

To Reproduce
Create a project with a dot in its name. Use a modern packaging tool that support pyproject.toml (flufl,i18n uses PDM). Upload that package to PyPI.

My Platform
n/a

Additional context
This may be related to the meta issue #12316 but I didn't see this specific issue discussed there (I could have missed it). It's also related to this discuss.python.org thread. It's probably also related to the root cause for a downstream bug report in GNU Mailman.

[di]

PyPI respects the Name field in the project metadata of the artifact it was provided. In this case, it was flufl-i18n.

This was set by the build backend you were using, which consumed it from pyproject.toml before producing your distributions. If the value in your pyproject.toml and the value in your distributions metadata don't agree, that's a bug in your build backend, not with PyPI, as PyPI is not aware of pyproject.toml at all.

[di]

(And to be clear, if the Name value was flufl.i18n, PyPI would respect that, both in the web UI and URL. See https://pypi.org/project/jaraco.develop/7.22.1/ for a recent example)

[dstufft]

Note that PyPI will rename the project to whatever the most recently uploaded artifact's Name field is. So this will be remediated upon your next release with a backend that doesn't normalize the name.

[warsaw]

Thanks @di - that's what I suspected. In this case I'm using PDM and pdm-backend. I bet build backends are stuck between a rock and a hard place here, as evidenced by the discuss.python.org meta thread. I want to at least capture the issue so we can begin to unwind and fix the ecosystem.

[di]

@warsaw I agree with your intent, but I don't think there's anything actionable for PyPI to do here.

Given that PEP 621 says this about the name field:

Tools SHOULD normalize this name, as specified by PEP 503, as soon as it is read for internal consistency.

I think if you disagree with this behavior in build backeds, you probably need to take it up as an ecosystem-wide issue instead (which you kind of already have in your discourse thread).

[dstufft]

The PEP that I hope to post this weekend clarifies that section of PEP 621, because I think that segment goes against what most people expected.

[warsaw]

@dstufft 💯

Thank you!

[di]

@warsaw Given that a future PEP would likely resolve this, and that PyPI would likely not need to make changes as a result of that PEP, is it OK with you if we close this?

[warsaw]

Yep, and thanks @di!

[warsaw]

@di I'm reopening this issue because I think there may still be a problem on the PyPI side. pdm-backend has been fixed to no longer normalize the package name metadata, but PyPI is still displaying the normalized name and pip install instructions.

Let's look at flufl.enum 6.0.1.

.whl METADATA excerpt:

Metadata-Version: 2.1
Name: flufl.enum
Version: 6.0.1
Summary: A Python enumeration package
Keywords: enum

sdist PKG-INFO excerpt:

Metadata-Version: 2.1
Name: flufl.enum
Version: 6.0.1
Summary: A Python enumeration package
Keywords: enum

Both metadata files are non-normalized, as we all now expect and want.

However, look at the PyPI page.

It is still displaying the normalized name and instructions. I've verified the metadata by actually downloading the .whl and .tar.gz so I know that PyPI has the right information. But it's still displaying the wrong data.

[dstufft]

What is doing the upload? Because PyPI also doesn't read the METADATA file itself, whatever is doing the upload does that and sends it alongside the file as data.

[ewdurbin]

@frostming: Doesn't look like you quite got it with your change: https://github.com/pdm-project/pdm-backend/blob/4476f86465644bdf6dc5f073fc5552db56937932/src/pdm/backend/_vendor/pyproject_metadata/__init__.py#L197

[dstufft]

Also https://github.com/pdm-project/pdm/blob/8724567b01aec583baca9f465367cd8251b2da11/src/pdm/cli/commands/publish/package.py#L182

[ewdurbin]

Closing, PyPI is behaving as described.

[warsaw]

Okay, thanks!

What is doing the upload? Because PyPI also doesn't read the METADATA file itself, whatever is doing the upload does that and sends it alongside the file as data.

TIL! I'm using pdm publish, so I think that's probably a bug in the PDM front-end. Maybe I can try flit.