Gitpython: Typing-related Exception in Python 3.5

[luator]

With the latest version from PyPi I'm getting an exception in Python 3.5 which seems to be related to type hints

Steps to reproduce

python3 -m venv venv_gitpython
. venv_gitpython/bin/activate
pip install gitpython
python3 -c "import git"

Expected behaviour

Import succeeds without error

Actual behaviour

Import fails with

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/felixwidmaier/venv_gitpython/lib/python3.5/site-packages/git/__init__.py", line 42, in <module>
    from git.config import GitConfigParser  # @NoMove @IgnorePep8
  File "/home/felixwidmaier/venv_gitpython/lib/python3.5/site-packages/git/config.py", line 238, in <module>
    class GitConfigParser(with_metaclass(MetaParserBuilder, cp.RawConfigParser, object)):  # type: ignore ## mypy does not understand dynamic class creation # noqa: E501
  File "/home/felixwidmaier/venv_gitpython/lib/python3.5/site-packages/git/config.py", line 279, in GitConfigParser
    repo: Union['Repo', None] = None) -> None:
  File "/usr/lib/python3.5/typing.py", line 552, in __getitem__
    dict(self.__dict__), parameters, _root=True)
  File "/usr/lib/python3.5/typing.py", line 512, in __new__
    for t2 in all_params - {t1} if not isinstance(t2, TypeVar)):
  File "/usr/lib/python3.5/typing.py", line 512, in <genexpr>
    for t2 in all_params - {t1} if not isinstance(t2, TypeVar)):
  File "/home/felixwidmaier/venv_gitpython/lib/python3.5/site-packages/typing_extensions.py", line 635, in __subclasscheck__
    raise TypeError("Literal cannot be used with issubclass().")
TypeError: Literal cannot be used with issubclass().

Tested with Python 3.5.2. The error does not occur with 3.6.9.

I saw that there are already plans to drop support for 3.5 soon, so unless this is an easy-to-fix issue, it's probably not worth spending time on it. However, in this case I think it would be good to officially drop 3.5-support now to avoid confusion.

[luator]

Note for others still stuck with Python 3.5 for whatever reason: 3.1.14 is the latest version that still seems to work.

[Byron]

Thanks for letting me know. Indeed, support for python 3.5 will be dropped via #1201 and I was the one setting the timer so could probably be the one to change it.
Generally, it's strange that our CI isn't catching this one. Maybe it's because python 3.5.10 is what we are using there and 3.5.2 really is too old.

The only way to properly fix this issue for python 3.5 users would be to yank 3.1.17 and release 3.1.18 without python 3.5 support.

Please let me know if this seems reasonable to you so I can get that done. There is also a chance that @Yobmod knows how to fix this and we can just do that instead.

[Yobmod]

I've re-checked the use of Literals, and can't see what is causing the problem in _our_ code. The tests for 3.5.10 pass and certainly import the code the exception points to.

The python version guards we put in ensure we are using typing_extensions.Literal for < 3.8, so we are using the same code for 3.5-3.7. We don't use issubclass() anywhere, so the actual exception is being thrown by the interpreter trying to interpret the types as opposed to runtime code. This looks like an incompatibility between typing_extensions and early versions of 3.5 that got fixed by 3.5.10. (That would also explain some errors we had previously that shouldn't have gotten past the tests). According to the docs, typing_extensions.Literal should work with 3.5, but it doesn't mention minor version changes. Looking at the typing_extensions module code, there are a few places that say "will not work for versions of typing older than 3.5.3".

Is it possible to specify minimum _minor_ version required on pypi, rather than dropping 3.5 early? Although I know other projects (e.g. Django) just say they only support the latest minor version of each major python.

If there are no big changes other than adding typing planned by september, maybe dropping 3.5 now will make no difference to users, as they can continue with their current working version (and types are already of limitied use in 3.5). It would make typing easier - just in GitConfigParser() there are a few places we couldn't type things correctly to keep 3.5 compat.

[luator]

Oh, I wasn't aware that my minor version was lagging so much behind. Unfortunately, it seems that 3.5.2 is the latest Python version that is provided on Ubuntu 16.04. But since the latter also reached end-of-life a view months ago, it is probably simply time for me to upgrade the whole computer.

I'm not familiar with pypi myself, but if it is possible to set a minimum minor version for the existing releases >3.1.14, that would probably be the best solution.

[Byron]

It doesn't look like patch levels are valid classifiers for python versions in setup.py/pypi.

By the looks of it keeping python 3.5 around also impedes typing in a few places and since it's end of life already it's probably best to drop support earlier - now there is a value proposition that previously I think didn't exist.

It's very interesting to see how big frameworks like django don't try to maintain backwards compatibility with minor versions, and I am happy to do the same once there is clear evidence that doing so will remove maintenance burden.

[Byron]

I am closing this issue as the following actions have taken place:

• python 3.5 support was officially removed with the newly released GitPython 3.1.18
• GitPython 3.1.17 was yanked
• GitPython 3.1.14 is now the last known working version for Python 3.5 no matter which patch release

All the above in concert will prevent his issue from arising for more users.

Thanks again for letting us known.