In some Python packages (such as python-jaraco-text) we use hatch instead of setuptools to build and install the wheel in EPEL 9 (because of missing features in the stock setuptools), but at least when the Python package name is in the form <A>.<B>, hatch creates the directory named <A>_<B>-<version>.dist-info instead of <A>.<B>-<version>.dist-info that setuptools creates. In our case the source directory is named <A>_<B>, which may or may not be part of the reason this happens. See bug 2324959 for the original bug report for python-jaraco-text. Reproducible: Always Steps to Reproduce: 1. Build python-jaraco-text using hatch (fedpkg mockbuild --with hatch / fedpkg --release epel9 mockbuild). Actual Results: The resulting RPM ships a /usr/lib/python[...]/site-packages/jaraco_text-[...].dist-info/ directory. Expected Results: The resulting RPM ships a /usr/lib/python[...]/site-packages/jaraco.text-[...].dist-info/ directory, same as when built with setuptools.
`python-hatchling` should be the more appropriate component here. But also other build backends should be checked. I thought that hatchling approach was the correct one backed by a PEP, but I need to study this a bit more. I will look into this from `scikit-build-core` side as well because I think the same normalization is done
Quick update, indeed `scikit-build-core` does the same normalization. I will check up with upstream about this as well
I agree that it was correct to reassign this to python-hatchling, the build backend, rather than hatch, the frontend. I’m happy to help coordinate discussion with upstream at https://github.com/pypa/hatch if you can determine that the behavior you’re seeing is actually incorrect. There was a similar upstream issue at one point, https://github.com/pypa/hatch/issues/841, but it wasn’t about dist-info directory names. I don’t think that this behavior has changed between python3-hatchling-1.21.1, in EPEL9, and python-hatchling-1.27.0, in Rawhide, but if we do think there is a bug here, we should probably check the most recent version before taking it upstream. Note that there are very good reasons, like minimum dependency versions or breaking changes, for the particular hatchling versions in the various Fedora and EPEL branches. I can backport patches carefully (except in EL10 where python3-hatchling is in the base OS and not under my control), but I can’t freely upgrade python-hatchling in stable releases.
(This comment is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2324959#c3.) It looks like https://github.com/pypa/setuptools/issues/3146 accurately describes the problem, and hatchling’s behavior appears to comply with https://packaging.python.org/en/latest/specifications/binary-distribution-format/#escaping-and-unicode. I’m not sure what the best workaround is, unless you can port away from pkg_resources in cherrypy.
Based on discussion here and in bug 2324959, I’m going to close this as NOTABUG since the reported behavior seems to be consistent with upstream design and with the relevant specifications. However, please do feel free to reopen this if new information shows that there is something to be fixed here.