conda smithy rerender -c auto failing with AssertionError on git repositories with index v3
#2116
Comments
|
I wonder if we should pin Edit: Nah, that'd be too late if the repo has been cloned already. We might need to catch the exception and print some informative error instead, because the user might need to re-clone. Edit 2: Maybe we can use |
|
We also probably need to start thinking of a long-term solution, which probably involves replacing GitPython. |
|
Dulwich looks well maintained, nice API, no
|
|
An argument in favor of |
|
No strong opinions. Note that |
Replace the use of GitPython package with pygit2. The latter seems to have better git support, in particular it supports the newer index versions 3 and 4. Since it is backed by the libgit2 library that is also used by Cargo, it seems to have the best chances of being updated for compatibility with new git versions. Admittedly, the API feels very low-level. In particular, it is necessary to explicitly request writing changes to index back, and explicitly reread it when it's modified externally (e.g. via another `pygit2.Repository` instance, as in tests). On the plus side, it does not invoke `git` at all -- everything is done by the library. Fixes conda-forge#2116
Replace the use of GitPython package with pygit2. The latter seems to have better git support, in particular it supports the newer index versions 3 and 4. Since it is backed by the libgit2 library that is also used by Cargo, it seems to have the best chances of being updated for compatibility with new git versions. Admittedly, the API feels very low-level. In particular, it is necessary to explicitly request writing changes to index back, and explicitly reread it when it's modified externally (e.g. via another `pygit2.Repository` instance, as in tests). On the plus side, it does not invoke `git` at all -- everything is done by the library. Fixes conda-forge#2116
Replace the use of GitPython package with pygit2. The latter seems to have better git support, in particular it supports the newer index versions 3 and 4. Since it is backed by the libgit2 library that is also used by Cargo, it seems to have the best chances of being updated for compatibility with new git versions. Admittedly, the API feels very low-level. In particular, it is necessary to explicitly request writing changes to index back, and explicitly reread it when it's modified externally (e.g. via another `pygit2.Repository` instance, as in tests). On the plus side, it does not invoke `git` at all -- everything is done by the library. Fixes conda-forge#2116
Replace the use of GitPython package with pygit2. The latter seems to have better git support, in particular it supports the newer index versions 3 and 4. Since it is backed by the libgit2 library that is also used by Cargo, it seems to have the best chances of being updated for compatibility with new git versions. Admittedly, the API feels very low-level. In particular, it is necessary to explicitly request writing changes to index back, and explicitly reread it when it's modified externally (e.g. via another `pygit2.Repository` instance, as in tests). On the plus side, it does not invoke `git` at all -- everything is done by the library. Fixes conda-forge#2116
Solution to issue cannot be found in the documentation.
Issue
When using new enough git (2.47.0 here), all newly cloned repositories are using index version 3. When trying to use conda-smithy on such a repository, I'm getting the following error:
This seems to be gitpython-developers/GitPython#1960. However, from what I understand it's unlikely to be fixed anytime soon, so perhaps some solution on conda-smithy end would be preferable.
A possible workaround is to force
feature.manyFiles=falsein git while cloning the repository.Installed packages
Environment info
The text was updated successfully, but these errors were encountered: