clufter fails to build with Python 3.9.0a2. Traceback (most recent call last): File "/builddir/build/BUILD/clufter-0.77.2/./run-dev", line 87, in <module> from . import __main__ File "/builddir/build/BUILD/clufter-0.77.2/clufter/__main__.py", line 11, in <module> from .main import run File "/builddir/build/BUILD/clufter-0.77.2/clufter/main.py", line 33, in <module> from .command_manager import CommandManager File "/builddir/build/BUILD/clufter-0.77.2/clufter/command_manager.py", line 16, in <module> from .command import commands, CommandAlias File "/builddir/build/BUILD/clufter-0.77.2/clufter/command.py", line 8, in <module> from collections import MutableMapping ImportError: cannot import name 'MutableMapping' from 'collections' (/usr/lib64/python3.9/collections/__init__.py) See https://docs.python.org/3.9/whatsnew/3.9.html#removed "The abstract base classes in collections.abc no longer are exposed in the regular collections module. This will help create a clearer distinction between the concrete classes and the abstract base classes." For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.9/fedora-rawhide-x86_64/01148355-clufter/ For all our attempts to build clufter with Python 3.9, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/package/clufter/ Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.9: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/ Let us know here if you have any questions. Python 3.9 will be included in Fedora 33. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.9. A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so it's important for us to get it fixed soon. We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.
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.