Bug 2338247

Summary:	Hatch creates the /usr/lib/python[...]/site-packages/[...].dist-info/ directory with the wrong name in some cases
Product:	[Fedora] Fedora	Reporter:	Ondrej Mosnáček <omosnacek>
Component:	python-hatchling	Assignee:	Ben Beasley <code>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	code, fedora, lbalhar, python-packagers-sig
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2025-01-15 18:09:22 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2324959

Description Ondrej Mosnáček 2025-01-15 15:48:03 UTC

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.

Comment 1 Cristian Le 2025-01-15 16:11:14 UTC

`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

Comment 2 Cristian Le 2025-01-15 16:32:07 UTC

Quick update, indeed `scikit-build-core` does the same normalization. I will check up with upstream about this as well

Comment 3 Ben Beasley 2025-01-15 16:40:32 UTC

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.

Comment 4 Ben Beasley 2025-01-15 16:51:08 UTC

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

Comment 5 Ben Beasley 2025-01-15 18:09:22 UTC

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.