this post was submitted on 07 Jun 2024
22 points (89.3% liked)

Python

6356 readers
1 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

๐Ÿ“… Events

PastNovember 2023

October 2023

July 2023

August 2023

September 2023

๐Ÿ Python project:
๐Ÿ’“ Python Community:
โœจ Python Ecosystem:
๐ŸŒŒ Fediverse
Communities
Projects
Feeds

founded 1 year ago
MODERATORS
 

I happen to write a lot of python code dealing with git repositories. Currently I am calling the git command line tool from python and interpret the output.

This solution really doesn't scale well. Can you recommend a python library that wraps git functionality?

I have found three:

  • GitPython: Seems to work well, but it is in maintenance mode, unlikely to be improved. It also does not have any type hints making working with it annoying.
  • pygit2: Seems well supported and has type hints. But it also seems very low level and pretty tedious to use.
  • dulwich: Looks very promising feature wise but I'm unsure how well it is supported. It seems like an ambitious project being largely done by just one person.
you are viewing a single comment's thread
view the rest of the comments
[โ€“] lordmauve@programming.dev 2 points 5 months ago

I recommend wrapping the git cli commands using subprocess, using porcelain output modes etc, and parsing the output.

We have had stability problems with GitPython (which wraps gitdb). On Linux gitdb does clever things with sliding mmap, which caused some crashes (in a multi threaded environment), and I found simple race conditions in the code for writing loose objects, which is about as simple an operation as can be, so I lost faith with it. I do use gitdb in one read-only single-threaded system; it's undoubtedly fast.

The biggest issues with git libraries are around the complexity of git configurations. Any independent reimplementation is probably going to support the most common 99% of features but that 1% always comes back to bite you! We use a lot of git features in service of a gigantic monorepo, like alternates and partial clones and config tricks.

If we use command-line git we get 100% compatibility with all git configuration and ODB features, and it's hard to ensure that with an independent git implementation (even libgit2).

When you say "that solution doesn't scale well" - we have made it scale. git itself scales well for operations it can perform natively, you just have to use the features effectively, often the high-level operations but sometimes lower-level commands like git cat-file --batch, git mktree --batch, etc. It's not as fast as gitdb but fast enough, and I can have high confidence that I can write something once and it won't break or cause problems later.