This is currently a blocker for python-terminado which is a blocker of several things that block python-pandas that I'm working to get into EPEL9. There appear to be no packages that currently depend on this in EPEL9: # dnf repoquery --whatrequires python3-hatchling Last metadata expiration check: 2:25:23 ago on Thu Jan 5 12:55:41 2023. This being the case perhaps it makes sense to just update it to the equivalent of rawhide.
This is also blocking python-jupyter-core
Hatchling is a build backend, like flit-core. It will only be a BR in almost all cases, and you are only looking for Requires. $ mock -r epel-9-x86_64 --enablerepo='*source*' --dnf-cmd -- repoquery --whatrequires python3-hatchling […] pipx-0:1.1.0-2.el9.src python-userpath-0:1.8.0-3.el9.src That’s still not a lot of dependent packages, and they should be compatible. I thought there were breaking changes in 1.0.0, but as I review the changelogs, I can’t find anything obvious. However, there are some dependency issues: No matching package to install: 'python3dist(packaging) >= 21.3' No matching package to install: 'python3dist(pluggy) >= 1' Note that these are runtime dependencies, not test dependencies, and that the required versions are the same in hatchling 1.5 as in the current release. These are not EPEL packages; I believe that this will prove to be an insurmountable obstacle, and you will have to package older versions of the dependent pacakges instead of a newer version of python-hatchling. It’s not surprising that a brand-new modern build backend would have dependency issues at this point in the EPEL9 lifecycle…. If you think I’ve missed something, please point it out, and I’ll be happy to consider it. Until then, I’m closing this as CANTFIX.
*** Bug 2224723 has been marked as a duplicate of this bug. ***
Hi, I've been playing with this today. The idea is to lower the packaging and pluggy versions in epel9 branch - basically just: - "packaging>=21.3", + "packaging>=20.9", - "pluggy>=1.0.0", + "pluggy>=0.13.1", in pyproject.toml files. I've ran the tests with the 20.9 and 0.13.1 versions respectively and they all passed. Then I've contacted Ofek, the author of Hatch and he confirmed the versions are not a 'hard' dependency. Quote: "I believe the older versions would actually work and I only set the minimum to be proactive." With that in mind, we can build hatchling up to 1.13.0, as 1.14 introduced trove-classifiers as a dependency, which is not included in rhel/epel repos. I've built 1.13 rpm and installed in on clean RHEL-9.3. Then I took a Fedora srpm of a project that previously had issues with older hatchling (as it uses hatch-vcs) on EPEL9 and it worked just fine. Looking at packaging guidelines, https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Automatically-generated-dependencies, - Packages MUST use the automatic Python run-time dependency generator. - Any necessary changes MUST be done by patches or modifying the source (e.g. with sed), rather than disabling the generator. @code Would you be ok with adding a patch file in epel9 branch or a similar workaround?
(In reply to Martin Hoyer from comment #4) > Hi, > I've been playing with this today. The idea is to lower the packaging and > pluggy versions in epel9 branch - basically just: > - "packaging>=21.3", > + "packaging>=20.9", > - "pluggy>=1.0.0", > + "pluggy>=0.13.1", > in pyproject.toml files. > > I've ran the tests with the 20.9 and 0.13.1 versions respectively and they > all passed. > > Then I've contacted Ofek, the author of Hatch and he confirmed the versions > are not a 'hard' dependency. Quote: > "I believe the older versions would actually work and I only set the minimum > to be proactive." Ofek is very careful. I trust his opinion on what should work. If the tests pass *and* Ofek thinks it should be OK, then I am happy. Note, that most of the tests for hatchling are actually in the hatch RPM, which is not ideal, but is hard to avoid due to their intermixture upstream. Still, I should be able to provide a recent (1.x) version of hatch as well, so we would be able to see any issues that popped up in the tests on the hatch side. > With that in mind, we can build hatchling up to 1.13.0, as 1.14 introduced > trove-classifiers as a dependency, which is not included in rhel/epel repos. > I've built 1.13 rpm and installed in on clean RHEL-9.3. Then I took a Fedora > srpm of a project that previously had issues with older hatchling (as it > uses hatch-vcs) on EPEL9 and it worked just fine. That sounds reasonable. We probably won’t see trove-classifiers branched for EPEL9 (No matching package to install: 'python3dist(setuptools) >= 61'), but being stuck at 1.13.0 would be a huge improvement over the status quo. > Looking at packaging guidelines, > https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ > #Automatically-generated-dependencies, > - Packages MUST use the automatic Python run-time dependency generator. > - Any necessary changes MUST be done by patches or modifying the source > (e.g. with sed), rather than disabling the generator. > > @code Would you be ok with adding a patch file in epel9 > branch or a similar workaround? Yes, loosening dependencies for EPEL9 (when adequately tested or justified) is a normal thing to do. Since you have done the legwork to confirm it should be safe, I’m happy with it. Furthermore, https://hatch.pypa.io/dev/history/hatchling/ does not show anything that looks like a nontrivial breaking change between 0.25.0 and 1.13.0. I will take a little time (probably up to a few days) to put together a set of PR’s implementing your suggestions and to confirm that there is no impact on existing packages in EPEL9, but I think you have a good plan. Thank you for the careful investigation.
Interestingly, it looks like I had already been loosening the packaging and pluggy versions for 0.25.0, based on a review of the upstream changelogs for those two packages.
Here’s the candidate PR for hatchling: https://src.fedoraproject.org/rpms/python-hatchling/pull-request/60 PR’s for hatch and python-hatch-vcs, and an impact check, to follow.
It looks like python-hatch-vcs has always required setuptools-scm>=6.4.0 for Python 3. I tried loosening the lower bound to 6.0.1 to match what is available in EL9, and I encountered one test failure: ============================= test session starts ============================== platform linux -- Python 3.9.16, pytest-6.2.2, py-1.10.0, pluggy-0.13.1 rootdir: /builddir/build/BUILD/hatch_vcs-0.3.0 collected 22 items tests/test_build.py ..F.. [ 22%] tests/test_build_config.py ...... [ 50%] tests/test_metadata_config.py .... [ 68%] tests/test_version_config.py ....... [100%] =================================== FAILURES =================================== ________________________________ test_fallback _________________________________ new_project_fallback = '/tmp/tmpiyvzvorn/my-app' @pytest.mark.skipif(sys.version_info[0] == 2, reason='Depends on fix in 6.4. 0 which is Python 3-only') def test_fallback(new_project_fallback): > build_project('-t', 'wheel') /builddir/build/BUILD/hatch_vcs-0.3.0/tests/test_build.py:86: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ /builddir/build/BUILD/hatch_vcs-0.3.0/tests/utils.py:30: in build_project _run_command(sys.executable, '-m', 'hatchling', 'build', *args, env=env) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ command = ('/usr/bin/python3', '-m', 'hatchling', 'build', '-t', 'wheel') kwargs = {'env': {'BASH_FUNC_which%%': '() { ( alias;\n eval ${which_declare} ) | /usr/bin/which --tty-only --read-alias --rea...k-clash-protection -fcf-protec tion', 'CONFIG_SITE': 'NONE', 'DEBUGINFOD_URLS': 'https://debuginfod.centos.org/ ', ...}} process = <Popen: returncode: 1 args: ('/usr/bin/python3', '-m', 'hatchling', 'b uild',...> stdout = 'Traceback (most recent call last):\n File "/usr/lib64/python3.9/runpy .py", line 197, in _run_module_as_main\n ret...nstead of https://github.com/u ser/proj/archive/master.zip use git+https://github.com/user/proj.git#egg=proj\n[ wheel]\n' _ = None def _run_command(*command, **kwargs): process = subprocess.Popen(command, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, **kwargs) stdout, _ = process.communicate() stdout = stdout.decode('utf-8') if process.returncode: # no cov > raise Exception(stdout) E Exception: Traceback (most recent call last): E File "/usr/lib64/python3.9/runpy.py", line 197, in _run_module_as_main E return _run_code(code, main_globals, None, E File "/usr/lib64/python3.9/runpy.py", line 87, in _run_code E exec(code, run_globals) E File "/usr/lib/python3.9/site-packages/hatchling/__main__.py", line 6, in <module> E sys.exit(hatchling()) E File "/usr/lib/python3.9/site-packages/hatchling/cli/__init__.py", line 26, in hatchling E command(**kwargs) E File "/usr/lib/python3.9/site-packages/hatchling/cli/build/__init__.py", line 75, in build_impl E for artifact in builder.build( E File "/usr/lib/python3.9/site-packages/hatchling/builders/plugin/interface.py", line 93, in build E self.metadata.validate_fields() E File "/usr/lib/python3.9/site-packages/hatchling/metadata/core.py", line 243, in validate_fields E _ = self.version E File "/usr/lib/python3.9/site-packages/hatchling/metadata/core.py", line 128, in version E self._version = self._get_version() E File "/usr/lib/python3.9/site-packages/hatchling/metadata/core.py", line 226, in _get_version E version = self.hatch.version.cached E File "/usr/lib/python3.9/site-packages/hatchling/metadata/core.py", line 1412, in cached E raise type(e)(message) from None E LookupError: Error getting the version from source `vcs`: setuptools-scm was unable to detect version for '/tmp/tmpiyvzvorn/my-app'. E E Make sure you're either building from a fully intact git repository or PyPI tarballs. Most other sources (such as GitHub's tarballs, a git checkout without the .git folder) don't contain the necessary metadata and will not work. E E For example, if you're using pip, instead of https://github.com/user/proj/archive/master.zip use git+https://github.com/user/proj.git#egg=proj E [wheel] /builddir/build/BUILD/hatch_vcs-0.3.0/tests/utils.py:43: Exception =========================== short test summary info ============================ FAILED tests/test_build.py::test_fallback - Exception: Traceback (most recent... ========================= 1 failed, 21 passed in 0.96s ========================= Is that what you saw? I would rather not have test failures, but I could probably justify skipping this test and shipping the package anyway if the real-world uses in EPEL9 packages seem to mostly work...
(In reply to Ben Beasley from comment #8) > Is that what you saw? I would rather not have test failures, but I could > probably justify skipping this test and shipping the package anyway if the > real-world uses in EPEL9 packages seem to mostly work... Thank You so much for looking into it Ben! I haven't actually tried to update the hatch-vcs. The python3-hatchling 1.13 rpm worked fine with the existing python3-hatch-vcs-0.2.1-1.el9 from epel.
Looking at the test, it says it depends on fix in 6.4.0, so I wonder how the previous epel version passed it. @pytest.mark.skipif(sys.version_info[0] == 2, reason='Depends on fix in 6.4.0 which is Python 3-only')
I somehow lost track of the fact that I already had python-hatch-vcs in EPEL9, and that I had already dealt with this. # EPEL9: This test fails with setuptools-scm < 6.4.0. Upstream assumes that # happens only for Python 2 (and skips the test accordingly), but we have # allowed setuptools-scm 6.0.1 on Python 3 as well. k="${k-}${k+ and }not test_fallback" %pytest -k "${k-}" %else %pyproject_check_import %endif Sorry to have brought you into my confusion!
PR for python-hatch-vcs is ready: https://src.fedoraproject.org/rpms/python-hatch-vcs/pull-request/13
No worries! Big thanks :)
I need python-filelock updated in EPEL9 to package Hatch. I opened a PR: https://src.fedoraproject.org/rpms/python-filelock/pull-request/9 Meanwhile, I will proceed with the COPR impact check for python-hatchling and python-hatch-vcs. If that looks good, I can go ahead and update those right away, and add hatch in a separate newpackage update once python-filelock is ready.
A COPR impact check[1] looks good, except that python-virtualenv will need some small packaging tweaks[2]. I’m going to wait a couple of days for any nit-picks on the python-virtualenv PR, then proceed. [1] https://copr.fedorainfracloud.org/coprs/music/hatch-epel9/packages/ [2] https://src.fedoraproject.org/rpms/python-virtualenv/pull-request/98
(In reply to Ben Beasley from comment #14) > I need python-filelock updated in EPEL9 to package Hatch. I opened a PR: > https://src.fedoraproject.org/rpms/python-filelock/pull-request/9 Even with this, packaging Hatch for EPEL9 looks like it will be a little messy. I’m not sure if I will put in the necessary effort or not. Even Hatch 1.6.1 has several dependency issues: No matching package to install: 'python3dist(keyring) >= 23.5' No matching package to install: 'python3dist(packaging) >= 21.3' No matching package to install: 'python3dist(platformdirs) >= 2.5' Yes, I could look at these case-by-case to see if they can be loosened, and maybe I will. Just getting hatchling and hatch-vcs up to date would be a huge benefit for Python packaging in EPEL9 even if Hatch itself ends up remaining impractical. ---- Note that gotmax23’s efforts to bring python-trove-classifiers to EPEL9[1][2] could allow updating python-hatchling in EPEL9 to the very latest version, currently 1.18.0. [1] https://src.fedoraproject.org/rpms/python-hatchling/pull-request/60#comment-151605 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2227079
It looks like python-keyring can be updated in EPEL9: https://src.fedoraproject.org/rpms/python-keyring/pull-request/22
I have been working on updating llhttp and python-aiohttp for CVE-2023-30589. I will get back to this python-hatchling update shortly. There is very little that needs to be done. I want to get to the point where I can run the Hatch test suite (which includes hatchling tests) locally on EPEL9 so that I can see if there are any issues I should pay attention to—even though Hatch and the dependency updates it needs won’t necessarily be included in the initial hatchling update for EPEL9.
I have started builds in epel9-build-side-70927.
FEDORA-EPEL-2023-d689ae7c5f has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-d689ae7c5f
There it is! I got Hatch packaged in the update, too. I’m happy with the amount of testing I did, but I bumped the stable-by-time setting up to two weeks. Any additional testing before it reaches stable would be welcome and appreciated.
FEDORA-EPEL-2023-d689ae7c5f has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-d689ae7c5f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Ben Beasley from comment #21) > There it is! I got Hatch packaged in the update, too. I’m happy with the > amount of testing I did, but I bumped the stable-by-time setting up to two > weeks. Any additional testing before it reaches stable would be welcome and > appreciated. Hi Ben, Sorry for asking a potentially stupid question, I don't have much experience with this process.. I see the the status of the https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-d689ae7c5f has been updated: ``` This update can be pushed to stable now if the maintainer wishes 5 days ago This update's test gating status has been changed to 'waiting'. 4 days ago This update's test gating status has been changed to 'ignored'. 3 days ago ``` What has to happen now, in order for the updates to make it to stable?
(In reply to Martin Hoyer from comment #23) > What has to happen now, in order for the updates to make it to stable? The update has the default “stable by karma” of 3. The “stable by time” is 14 days; I increased it from the default and minimum of 7 days because I wanted to allow a little extra time for anyone who wanted to test it, since even though it should be a compatible update, it’s a fairly significant one. So there are three routes to stable: - Two more people test it and give it positive karma, in which case it would go stable right away - The 14 days elapse, which should happen this Thursday, August 17; I expect this is what will happen - I could now push it manually; but I’m not planning to do that, because I chose the 14 day testing period Hope that clears things up.
(In reply to Ben Beasley from comment #24) Awesome, thank You very much for the explanation. I'll try to see if I can find someone interested in testing it as well.
FEDORA-EPEL-2023-d689ae7c5f has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.