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.