Description

connordelacruz

opened on May 12, 2021

Issue body actions

Currently, the API reference section for GitPython on readthedocs.io just shows the headings:

This is happening for version 3.1.15, "stable", and "latest":

• https://gitpython.readthedocs.io/en/3.1.15/reference.html
• https://gitpython.readthedocs.io/en/stable/reference.html
• https://gitpython.readthedocs.io/en/latest/reference.html

3.1.14 looks fine, however:

https://gitpython.readthedocs.io/en/3.1.14/reference.html

it seems like something about the autodocs changed between 3.1.14 and 3.1.15

Reacted by Patrick Duncan, kraiskil and DasSkelett

Activity

1. Byron

   added

   acknowledged

   help wanted

   on May 13, 2021
2. Byron commented on May 13, 2021

   

   Byron

   on May 13, 2021

   Member

   More actions

   It becomes clear that the addition of types broke the API doc rendering - 3.1.15 (YANKED) added types as major feature.

   Thus far there is no new release, but more and more types are added right now and there is no turning back from it.

   

   What they call latest seems pretty old judging by the build logs. However, the most recent one is three weeks old and I add it here in case it contains useful information. Maybe you could have a look, too.

   https://readthedocs.org/api/v2/build/13566171.txt

   There are lot of failed imports of gitdb, but it's merely a warning.

   Here is the log for 3.1.14, the latest working one.

   https://readthedocs.org/api/v2/build/13122709.txt

   There we don't have the warnings related to gitdb. Maybe that's a lead, and maybe that tells us it's not related to types at all but to something related to how gitdb is handled.

   Maybe there would be a way to git-bisect while running autodoc to figure out which commit exactly is causing this, when studying the changes between 3.1.14 and 3.1.15 I saw nothing explicitly related to gitdb.

   Any help is appreciated.
3. Yobmod commented on Jun 21, 2021

   

   Yobmod

   on Jun 21, 2021

   Contributor

   More actions

   Hi,

   I've been looking into this, and I don't think it has anything to do with typing. I've checked every PR and all the commits in the 1 typing-PR between v3.1.14 and v3.1.15.

   However, I eventually noticed that Gitdb docs are also broken since v4.0.6. That was released 25th March, in between Gitpython v3.1.14 and v3.1.15, so changes there were pulled across to here, as a submodule or from pypi. I've not PRed any typings to Gitdb yet, so that cant be the cause.

   I've not used autodocs before, so I can't check if pinning to older dependancies (before changing the signing key? earlier smmap?) fixes it. When the docs are built, where do the files go? I tried removing the /build cleanup step on my fork, but still not getting any files I can check.

   Another thing i noticed: pythonpackage.yml used to import gibdb and ssmap as submodules. This now fails to pass tests unless gitdb is also pip installed (fails with "fatal: exec 'rev-list': cd to 'gitdb/ext/smmap' failed: No such file or directory" and "ModuleNotFoundError (No module named 'gitdb')".
   (But also fails if the submodule import removed instead!)

   Reacted by Sebastian Thiel
4. Byron commented on Jun 22, 2021

   

   Byron

   on Jun 22, 2021

   Member

   More actions

   I've been looking into this, and I don't think it has anything to do with typing. I've checked every PR and all the commits in the 1 typing-PR between v3.1.14 and v3.1.15.

   Thanks a lot, me concluding that this happened due to typing was an unvalidated assumption, my apologies.

   When the docs are built, where do the files go?

   From the doc directory make html should build docs into the doc/html subdirectory if sphinx-build is available in the PATH.

   Another thing i noticed: pythonpackage.yml used to import gibdb and ssmap as submodules. This now fails to pass tests unless gitdb is also pip installed (fails with "fatal: exec 'rev-list': cd to 'gitdb/ext/smmap' failed: No such file or directory" and "ModuleNotFoundError (No module named 'gitdb')".

   That's interesting, CI seems to be green. However, that in conjunction with some changes to GitDb might actually help to solve this, and locally reproducing the docs build is certainly the way to go.
5. Yobmod commented on Jun 23, 2021

   

   Yobmod

   on Jun 23, 2021

   Contributor

   More actions

   Yep, the CI works because gitdb was added to test-requirements.txt in May (in order to get CI to pass adter ModuleNotFoundError apeared).

   So in pythonpackage.yml gitdb/smmap is getting imported from test-requirements.txt afterbeing import as submodules and masking any potential problems from submodules.
   Doesn't identify the issue, but something about gitdb submodule changed then, coincident with the docs breaking.

   Reacted by Sebastian Thiel
6. Byron commented on Jun 23, 2021

   

   Byron

   on Jun 23, 2021

   Member

   More actions

   

   I think it's fixed now. Please see the linked issue for details.
7. Byron

   closed this as completedon Jun 23, 2021

Issue actions