Jrnl: Python 3.9 build is failing with import error ('Mapping' from 'collections')

[wren]

The tests that we run on the nightly version of Python have started failing with this error:

[ImportError]                                                    
cannot import name 'Mapping' from 'collections' (/home/travis/virtualenv/pyt  
hon3.9-dev/lib/python3.9/collections/__init__.py)

I haven't had a chance to look into this, yet, but 3.8 just came out, and 3.9 is still in alpha, so we have some time. But we should fix this soon.

Example: https://travis-ci.com/jrnl-org/jrnl/jobs/274130952

[clbarnes]

Abstract base classes are now in collections.abc rather than collections; pretty sure is the case for all versions jrnl supports. This should have raised deprecation warnings for a few versions (collections.abc was new in 3.3).

From the looks of it, the issue is not in jrnl, or in the version of poetry jrnl uses, so it's probably in one of jrnl's dependencies, although I would have expected poetry to give a more helpful error message if that were the case. Couldn't find any problematic usages of Mapping in the site-packages of a virtualenv with jrnl installed in it, which suggests it's somewhere in the dependency tree of the dev dependencies.

[wren]

@clbarnes Thanks for looking into this! That seems like it would be an easy fix if it were in jrnl, but I guess we'll have to do a dependency audit to deal with this.

[clbarnes]

My strategy was just to install the environment and grep in site-packages for Mapping, but I only got as far as using the version from pip as poetry disagrees with my dev setup. Does that sound like it would be a sufficient strategy? Wheels get unzipped when they're installed, right?

[dbxnr]

passlib is definitely importing collections.Mapping - (pwd.py:13)
pytz is importing it as well, although it's checking for an ImportError (lazy.py:8)

There are a few others, but they're checking the python version before importing (Py2 compatibility)

[clbarnes]

Are the dependency versions in pyproject up to date? Passlib's default branch looks like it's using MutableMapping, and correctly has it in the try/except.

[wren]

@clbarnes The dependencies in the lock file should be up to date as of about 2 weeks ago.

[MinchinWeb]

It appears the actual issue here (or at least the first time Travis hits it) is with virtualenv. Upstream ticket --> https://github.com/pypa/virtualenv/issues/1449

Per the upstream ticket, this should be fixed in newer versions of virtualenv...

In any case, this is why the dev version of Python is on the testing matrix...

[wren]

Good find, @MinchinWeb!

[micahellison]

According to the Python 3.9 release schedule, 3.9 final will be out on October 5 this year. It's critical to have a fix or workaround in place by then.

[wren]

I would love to prioritize this for the next version (v2.4). If anyone wants to submit a PR, I would really appreciate it, and will make sure to fast-track it.

[ivanguy]

https://docs.python.org/3.9/whatsnew/3.9.html#you-should-check-for-deprecationwarning-in-your-code

Aliases to Abstract Base Classes in the collections module, like collections.Mapping alias to collections.abc.Mapping, are kept for one last release for backward compatibility. They will be removed from Python 3.10.

[wren]

Fixed by #909