I read through the docs of pygit2, how is it too low level compared to using direct console output?
if you need complex workflows, couldn't they be built over the convenience of the library?
Welcome to the Python community on the programming.dev Lemmy instance!
Past
November 2023
October 2023
July 2023
August 2023
September 2023
I read through the docs of pygit2, how is it too low level compared to using direct console output?
if you need complex workflows, couldn't they be built over the convenience of the library?
Maybe pygit2 is indeed the way to go. When I looked into it a while back it looked very low level like it only implemented the git plumbing. But maybe I looked at the wrong part of the docs, because it doesn't look too bad.
Dulwich is decent. Has some good porcelain functions. But it's organized kind of weird. I sort of recall it's the only one that isn't a wrapper on the git CLI?
Anyway, they all kind of suck in my experience.
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.
Honestly if you already know all the git commands? Iβd use sh
You'd still only get strings as returns. No objects modeling git concepts.
Fair point, I usually use exit codes
We have historically used GitPython a lot, but in a recent project I tried git via sh instead. It works great. If you already know the git cli, this feels very ergonomic to use.
With no more details? I'd go with Dulwich. libgit2
is overly picky about inputs and can't be hacked apart at all, and this affects its bindings too. I recently found myself monkey-patching Dulwich to allow otherwise-forbidden characters in refs, and this would have been fundamentally impossible with anything on top of libgit2
.
I usually use subprocess. Python has a very nice API for calling subprocesses.
I used pygit2 a few years ago and it was easy. Canβt complain.
Sounds like pygit2 is the move until dulwich has a bit more support.