Experiencing the same here.

from gitdb.utils.compat import (
 ModuleNotFoundError: No module named 'gitdb.utils.compat'

We're using the 3.0.5 release. Looks like the latest release to gitdb (3.0.2) has caused the issue - if I add gitdb2==3.0.1 to my requirements.txt, it's fixed.

@davidwneary Ah, that issue is due to GitDB v3.0.2 removing gitdb.utils.compat.
I'll push a fix momentarily.
That import was removed with GitPython v3.0.6 (b5dd2f0, a10ceef, 5d22d57) so the latest versions shouldn't have that issue.

@mell0 gitdb2 is the same gitdb library renamed on PyPI due to loss of access to the original PyPI account. See gitpython-developers/gitdb#45, gitpython-developers/gitdb#47, and pypa/pypi-support#204. The import remains gitdb.

@davidwneary Actually, that import was removed with v3.0.6. This should be resolved in the latest versions.

@mell0 I'm unable to reproduce this in a new environment with the latest versions of both libraries, i.e. gitpython v3.0.8 and gitdb2 v3.0.2. If your issue is different, can you provide the details of your environment, e.g. gitpython, gitdb2, and python versions, and the full traceback?

Hi,

Problem is when trying to install an older version for GitPython which I had in my test requirements file, to be specific v3.0.4. I understood that this was fixed in versions above v3.0.6. It's just that v3.0.4 should have used in its requirements working gitdb2 version with compat included, because now I have a lot of deployment fails of my apps and I'm sure it's not only me. In my opinion requirements should contain more specific version of the dependencies not just >=, because thus way people using older version and relying on it are suffering and in general at the moment older versions <=v3.0.6 are not working.

To reproduce, just create new virtual env, try to install GitPython==3.0.4, and try to import it.

I agree that the versioning is less than ideal here. In fact, GitPython shouldn't have been using GitDB compatibility shims in the first place, causing the removal to be a breaking change, as they should have been internal rather than exposed.

I've gone ahead and restricted the gitdb2 version to < 4 now with e81fd54 to mitigate future issues like this, and it should be part of the next release.

However, there's not much that can be done at this point for older versions that rely on gitdb2 < 3.0.2. Even if the GitDB removal was reverted, since it wasn't restricted to < or <= any certain version for GitPython, any breaking change in the future would still break older GitPython versions.
But since the only GitPython version requirement for gitdb2 was >= 2 for older versions, you can simply specify gitdb2 < 3.0.2 in your own dependencies if you want to continue using an older version of GitPython.

In fact, there was an issue with the formatting of the version specifier that wasn't fixed until GitPython v3.0.6, so you should be able to specify and install any gitdb2 version (although I can't guarantee that it'll work with < 2). It's just that, by default, the latest version will be installed.

@Harmon758
You could do a post release (https://www.python.org/dev/peps/pep-0440/#post-releases).
An hotfix for such a thing would avoid many unexpected problems by devs that tagged this version in order to have stable code, but suddenly still get an error.

I would also argue that using the patch number instead of (at least) minor for such big refactoring isn't really a best practice to avoid situations like this in the future.

When can we expect this next release?

I don't think creating a post-release for this is a good idea. As PEP 440 says, it's meant for issues that don't affect the actual software, like changes in release notes, and shouldn't be used for actual bug fixes. In addition, to cover every old version affected by the issue, we'd have to do 9 post-releases for 2.1.12 - 2.1.14 and 3.0.0 - 3.0.5.

I agree that some of the recent releases should have been minor version bumps rather than patch version bumps, but I've only very recently become a maintainer and Byron has been doing the releases. We're still working on our development and release process, but we have an open line of communication now that should help.

Apologies for any hassles this issue might have caused, but the root cause of the issue is that gitdb2 was not version locked. Having a minor version bump instead of a patch version bump wouldn't have affected the issue at all. In fact, any breaking change in GitDB, even with a major version bump, would have had the potential of breaking old GitPython versions.

Future issues like this should be mitigated now with gitdb2 version-locked to < 4. If an unintentional breaking change in a patch version bump were to occur again, we could simply revert the change in another patch version bump and release it with a major version bump.

As for resolving the current issue, if you're using an older version of GitPython, you can simply upgrade to the latest version of either major version, i.e. 3.0.8 or 2.1.15. Upgrading to 3.0.6 or 3.0.7 should resolve the issue as well. If you need to use an older version and can't upgrade, you'll have to add a requirement for gitdb2 < 3.0.2.

And should it become necessary, we might even be able to fight fire with fire, and overwrite a previous release of gitdb.
Personally I would prefer the affected folks to upgrade, but arguments can be made for the alternative above.

I ran into the same issue. I uninstalled GitPython and then reinstalling it to get past the original error and then I ended up pinning the GitPython version higher than 3.1.0 and a fully successful build.