It looks like a bug in hatch, which we use instead of setuptools to build the package in EPEL 9 - I reported it in bug 2338247.

Cc @fedora

Thanks for the CC. My understanding is that any field in the dependencies must be normalized, e.g. lowercased and special symbols changed to _ and any tools that query the project name must do a similar normalization. It seems that indeed `setuptools` does not normalize like this. Should check if there is a specific PEP that clarifies this behavior. If I understand the issue correctly, `importlib.metadata` does this correctly, but `pkg_resources` (at least the version in EPEL9) does not? Usage of `pkg_resources` outside of `setuptools` should be deprecated, but I guess adding the symlink is an appropriate solution. But first can we check of Fedora if using the same patches, that the names are again similarly normalized by hatchling and what does the most recent `pkg_resources` do in this case?

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.

Thanks Ben. Indeed I got the same reference from `scikit-build-core`. The upstream issue is interesting because it contradicts the report by Joao, i.e. `jaraco.text` should also be failing, but maybe it's a difference in versions. And to verify, is this issue related to a package being built or a user experience?

Since we cannot update `setuptools` anyway and if the `pkg_resources` there does indeed work with the `jaraco.text` symlink, I would say that we should create those symlinks for the jaraco packages that we have patched. But we should double-check first that this would not affect `importlib.metadata` path.

Oh, at least for python-cherrypy they have fixed the issue in 18.10.0, and at least adding that fix should be easy. But open to either approach, whichever would be more reliable. Ah, and I get it why this was not picked up by the impact check earlier on since this would not actually fail the build, just return a bogus `__version__`.

(In reply to Cristian Le from comment #4)
> Thanks Ben. Indeed I got the same reference from `scikit-build-core`. The
> upstream issue is interesting because it contradicts the report by Joao,
> i.e. `jaraco.text` should also be failing, but maybe it's a difference in
> versions. And to verify, is this issue related to a package being built or a
> user experience?

The problem appears to be that pkg_resources can’t handle the normalization. I just installed python3-jaraco-text and python3-setuptools in an EPEL9 chroot and saw the same thing, as you would expect:

Python 3.9.21 (main, Dec  5 2024, 00:00:00) 
[GCC 11.5.0 20240719 (Red Hat 11.5.0-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkg_resources
>>> pkg_resources.require('jaraco.text')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 886, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 772, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'jaraco.text' distribution was not found and is required by the application

> Since we cannot update `setuptools` anyway and if the `pkg_resources` there
> does indeed work with the `jaraco.text` symlink, I would say that we should
> create those symlinks for the jaraco packages that we have patched. But we
> should double-check first that this would not affect `importlib.metadata`
> path.

It seems like even the latest (deprecated, then removed) pkg_resources doesn’t handle this properly, so updating setuptools wouldn’t help even if it were possible.

Is it possible to update cherrypy in EPEL9 to 18.10.0, which replaces pkg_resources with importlib.metadata (https://github.com/cherrypy/cherrypy/issues/2019, https://github.com/cherrypy/cherrypy/issues/1973)? Or if there are too many dependency issues or breaking changes to consider that? If so, perhaps just https://github.com/cherrypy/cherrypy/pull/1993 can be backported?

(On preview, I see that you arrived at a similar approach in https://bugzilla.redhat.com/show_bug.cgi?id=2324959#c5.)

(In reply to Cristian Le from comment #4)
> Thanks Ben. Indeed I got the same reference from `scikit-build-core`. The
> upstream issue is interesting because it contradicts the report by Joao,
> i.e. `jaraco.text` should also be failing, but maybe it's a difference in
> versions. And to verify, is this issue related to a package being built or a
> user experience?

I believe this would fall under a "user experience" kind of thing.

As Ben has shown in his last comment, the problem arises when importing the package through 'pkg_resources'.

I haven't checked lately whether newer versions of cherrypy have dealt with the issue that I was seeing though, so I can't provide further info on that.

I do wonder if relying on a newer version of cherrypy is the best outcome here though. Keep in mind I don't have package maintenance experience, but I would assume that, until `pkg_resources` is dropped, even if deprecated, support for it would still exist? Either way, I defer to your expertise on that.

FEDORA-EPEL-2025-3c74eed70b (python-jaraco-text-4.0.0-3.el10_0) has been submitted as an update to Fedora EPEL 10.0.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-3c74eed70b

FEDORA-EPEL-2025-3c74eed70b has been pushed to the Fedora EPEL 10.0 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-3c74eed70b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

The #2324187 fixes only for el10. The el9 also affected by this issue

Also, issue for el9 can be resolved, via build python-cherrypy 18.10.0


```
[root@c9s]# python
Python 3.9.21 (main, Dec  4 2024, 00:00:00)
[GCC 11.5.0 20240719 (Red Hat 11.5.0-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cherrypy
>>> cherrypy.__version__
'18.10.0'
>>>
```

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.