Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1791769
Summary: | clufter fails to build with Python 3.9: ValueError became an ImportError | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Miro Hrončok <mhroncok> |
Component: | clufter | Assignee: | Jan Pokorný [poki] <fedora> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | cstratak, hugovk+redhatbugzilla, mhroncok, vstinner |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-06-11 11:48:22 UTC | Type: | Bug |
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: | 1803234, 1785415 |
Description
Miro Hrončok
2020-01-16 12:48:37 UTC
Thanks for the heads-up and details.
> it's important for us to get it fixed soon
Looking...
https://koji.fedoraproject.org/koji/taskinfo?taskID=40681936 -> clufter-0.77.2-6.fc32 Miro, one really subtle thing coming to 3.9, if you happen to read this (not that ValueError did not use to be suspicious to me from the beginning per the original comments, but still, rather unexpected something like that would occur this relatively late to the major version): https://pagure.io/clufter/c/2b1b834972a8834410d9e0c348c9aeda07c010af?branch=next What do you mean by "relatively late"? Python 3.X and 3.X+1 subtle incompatibilities are not getting any lower with higher X. Anyway, I suppose the ValueError was a bug, now fixed. I've meant, I find it rather wild west when something established since at least 2.6 receives this "tweak" as late as in 3.9. Now, someone starts developing with 3.9, only for a surprise moment at the innocent place like this when deployed with say 3.8 (because that's what's supported in their distro of choice, for instance). Maybe 3.x line will go on virtually forever and cognitive load on breaking changes will not decline in time and everyone's fine with that, but IMHO 2.x set some expectations that incompatibilities are very very rare after 2.6.0, even such a change would likely be no-go between 2.6 these two. I dunno, just feelings, based on not expecting something like this coming without warning (unlike with the former problem you've raised, there was some head time about it eventually happening, at least, if only I had paid attention) :-) Also ... proactive defence against library/environment changes like that (once/if one gets comfortable that these are apparently inevitable) is one of the most terrible ideas perhaps ... to routinely start excepting the most generaly exception classes (actual antipattern?). Do Python core devs want to send such a signal and teach the crowds this is an encouraged way of forward compatibility maintenance? It doesn't look to me this was judged taking all these possible implications into account, but afterall, who am I? (purely rhetorical to justify my stance that perhaps owed some explaining, no more replies insisted on, thanks a lot for pushing this forward in such as graceful manner) Victor, do you know where this was changed and whether it is a known difference between 3.8 and 3.9? Oh, never mind, found it, first thing on https://docs.python.org/3.9/whatsnew/3.9.html "__import__() now raises ImportError instead of ValueError, which used to occur when a relative import went past its top-level package." https://bugs.python.org/issue37444 Yep, what was also explicitly linked in the commit msg. That assumes your attention will survive all those items, if you have enough discipline to review that to begin with. Please see PR https://github.com/jnpkrn/clufter/pull/1 for the collections.abc fixes. Hugo, thanks for the effort ... but now I plain regret that I don't appear to do a good job of announcing: - GitHub serves me rather as a mirror and Travis CI runner (that's why I also disabled issues there), primary is pagure.io hosting: https://pagure.io/clufter -> I've just fixed that (again, my apologies!) - master branch serves to host stable code at the latest release snapshot, development happens on "next" branch ("Development version", very rarely, I even force-push there -- never to master, and only master hosts the tags) -> have marked next as "default branch" (I don't think there was this option back then and haven't looked at the settings until now) -> for good measure, did the same at pagure.io primary hosting -> will add more to the README file That will hopefully explain (or in hindsight be explained by) the https://pagure.io/clufter/c/2b1b834972a8834410d9e0c348c9aeda07c010af?branch=next link in [comment 2] above. Now to your changes, they in fact redo the pre-existing commit I already had in next by that time: https://github.com/jnpkrn/clufter/commit/b83e3091a7febd715cc0502dc154e43edb2d44f1 if you want GH, otherwise https://pagure.io/clufter/c/b83e3091a7febd715cc0502dc154e43edb2d44f1?branch=next (Also note that this alone wasn't sufficient for a successful test suite run, see ValueError/ImportError discussed above). That being said, Hugo, to retain at least something of your effort, I'll be grateful if you can amend that pull request to only contain that 3.9 addition to .travis.yml file, and retarget it against next branch. Thanks in advance! It will make it to master right before the next release. And thanks for understanding, sorry about this perhaps unexpected obstacle, I deserve my portion of non-transparency shame here. No problem! I've updated the PR, cheers! Gladly taken, thanks! (didn't mean to flip the status, something annoying going on) This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32. This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component. This comment is mass posted to all bugs blocking the Python 3.9 tracker, sorry if it is not 100 % relevant. When in doubt, please ask. The Python 3.9 rebuild is in progress in a Koji side tag. If you fix this bug, please don't rebuild the package in regular rawhide, but do it in the side tag with: $ fedpkg build --target=f33-python The rebuild is progressing slowly and it is possible this package won't have all the required build dependencies yet. If that's the case, please just leave the fix committed and pushed and we will eventually rebuild it for you. You are not asked to go and try rebuild all the missing dependencies yourself. If you know there is a bootstrap loop in the dependencies, let me know and we can untangle it together. If you want to test your fix or reproduce the failure, you can still use the Copr repo mentioned in the initial comment of this bug: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/ Python 3.9 update: The f33-python side tag is currently being merged. New builds in f33-python are no longer possible, but python3 is not yet updated to Python 3.9 in rawhide. You can check when Python is Python 3.9 with: $ koji wait-repo f33-build --build python3.9-3.9.0~b1-3.fc3 And build the packages normally after that. This is a bulk close of Python 3.9 bugzillas of packages that successfully built. If this remained open for a reason, I am sorry and feel free to reopen. |