cannot import name 'OrderedDict' from 'typing'

[ghost]

Hello, something about recent changes broke our CI.

cannot import name 'OrderedDict' from 'typing' (/usr/lib64/python3.7/typing.py)

I'm not sure what the issue is exactly but there seems to be some condition to determine where OrderedDict comes from in config.py

We have Python 3.7.1

Python 3.7.1 (default, Oct 22 2018, 10:41:28) 
[GCC 8.2.1 20180831] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from typing import OrderedDict
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name 'OrderedDict' from 'typing' (/usr/lib/python3.7/typing.py)
>>> from collections import OrderedDict
>>> 

We have this problem with gitpython-3.1.20 from pypi

[Yobmod]

Hi, thanks for the report.
Its a problem due to typing changing api in minor releases.
It should work in 3.7.2, if you can upgrade.
Or its fixed in the main branch, if can install from git.
Or will work in 3.1.18 (but will lose typehints) or the next release!

[ghost]

Thank you for acting so fast.

[Yobmod]

Closing this as it should be fixed in the newest release (3.1.24).

If anyone still hits this issue, please comment and reopen.

[tucked]

This was first included in a release that dropped 3.6 support (in a patch version ☹️)... meaning it only fixed 3.7.0 and 3.7.1.
We're still affected over in 3.6 land (which isn't even EOL yet).

[Byron]

This was first included in a release that dropped 3.6 support (in a patch version ☹️)…

I am sorry for the inconvenience. It's probably not very clear how the stability of GitPython is affected by its support for the underlying python interpreter. The status quo is to drop support in patch levels, but I'd have thought this is only done at EOL and not before.

Since the supported python versions are distributed with the setup.py file, I'd hope that whichever tool you are using isn't auto-updating to a patch level that doesn't support its own python interpreter anymore.

We're still affected over in 3.6 land (which isn't even EOL yet).

It's EOL in two weeks, but if it wasn't, is there a way to help out in such a situation?

[tucked]

I feel like the entire response I wrote up is kinda... whiny 😕 I'm sorry for that. I'll leave it anyways in case there's any value to be had, but I realize the project is in maintenance mode and everything is best-effort. So, I'm grateful a fix is available in any form 🙏

---

Not sure if this project follows semver, but dropping support is technically a backwards-incompatible change...
pip isn't picking up the new version inappropriately, but that's the problem: pip isn't picking up the new version (i.e. so we don't get the fix).

This fix (3347c00) went in before the commit that dropped py36, so a release could have been cut in between. (I actually had to dive in to see that it went out in the same release, 3.1.22... I was skipping over all the yanks.)

If there had been a minor or major version bump, we could backport the fix and cut a new release, but we can't really do that at this point without adding a 4th release digit (e.g. 3.1.18.1).

I'm sure excluding 3.6 wasn't intentional. It's just that fixing it after dropping py36 doesn't really buy much... AFAIK, superseded Python patch releases are EOL, so fixing support for only 3.7.0 and 3.7.1 just seems like the same effort for way less gain.