Upvoting this. We also need it, since it is now the preferred build tool for many python libraries and it is a matter of fact already present in EPEL9.
I have no idea if this is possible or not. Hatch/hatchling, as a project, is *much* newer than EL8. If it is possible, it is probably not trivial, and would require some work on adjusting and branching dependencies. Even getting a semi-current version into EPEL9 required some patching of dependency bounds, expected output formats in tests, and so on. If it’s possible to package python-hatchling in EPEL8, it would almost certainly be just hatchling, not hatch, which means (due to the way the upstream tests are organized) that it would not be possible to run any tests on hatchling at all. I will investigate further when I have a little time, and after I finish working on bug 2265089.
Current versions no longer support Python 3.6, so we'd need to package some old version of hatchling. If you want to support python3.6 and EPEL 8, you'll have better luck with setuptools or flit-core, both of which are already packaged.
So, in addition to https://bugzilla.redhat.com/show_bug.cgi?id=2265090#c3, looking at the current version of hatchling: - Upstream wants python3-packaging >= 21.3; the OS has 16.8. - Upstream wants python3-pathspec >= 0.10.1; the OS has 0.6.0. - Upstream wants python3-pluggy >= 1.0.0; the OS has 0.6.0. - Upstream wants python3-trove-classifiers; it is not packaged, but perhaps it could be added to EPEL8? It’s hard to have any confidence that arbitrarily loosening these dependency version bounds would be safe, especially given that the packaged versions are quite a bit older than the upstream bounds, and given that we cannot run any tests without also satisfying all of the runtime dependencies of hatch[1], which are numerous[2]. Note that the 1.0.0 release of hatchling happened about three years after the original release of RHEL8, and so packaging an older version would not help with the dependency problems as much as one might hope. Another problem is that the Python packaging macros in EPEL8 use setup.py (pyproject-rpm-macros are available beginning with EPEL9), but hatchling is a modern build system that has always exclusively used pyproject.toml. There may be some non-obvious workaround for this with a “stub” setup.py; I am not sure if setuptools is new enough in EL8 for something like that to work. Unfortunately, the absence of hatchling is just the first of many obstacles you will face in trying to package current current releases of fast-moving Python packages for the system Python in RHEL8/EPEL8, a distribution that is already almost five years years old and mostly contains five-year-old packages. In a Matrix chat, Maxwell G (gotmax23) wrote, “Packaging it for python3.11 or another newer alternative Python stack in RHEL 8 could work, but I don't think packaging it for the default python3 stack is practical or a good idea.” Overall, I won’t stand in the way if someone finds a way to package this sensibly and with confidence, but I’m not planning to attempt it myself. [1] https://src.fedoraproject.org/rpms/python-hatchling/pull-request/73 [2] https://github.com/pypa/hatch/blob/hatch-v1.9.3/pyproject.toml#L40-L56
(In reply to Maxwell G from comment #3) > Current versions no longer support Python 3.6, so we'd need to package some > old version of hatchling. If you want to support python3.6 and EPEL 8, > you'll have better luck with setuptools or flit-core, both of which are > already packaged. Formal upstream support for Python 2.7 hung on until hatchling 0.25.1 and was dropped in 1.0.0; upstream support for Python 3.6 ended after hatchling 0.5.0, which was a *very* early and immature release.