Re: [RFC PATCH 0/6] [RFC] Introduce cgit-rs, a Rust wrapper around libgit.a

On 2024-08-07 at 18:21:25, Josh Steadmon wrote:

We are putting error handling on hold for now since it is too complex
and we intend other CLIs to be our first customers, in which case
printing out errors is not the worst.

While I think that's okay for now, that really needs to be one of the
first priorities of things we fix.  I have some ideas about an approach
which we can take, which I'll send out in the next few days in a
separate thread.

While the wrapper itself lives in contrib/, there are a couple of
patches that touch git.git code. These patches are necessary for the
wrapper, but not for git.git itself, which may seem unnecessary to
merge. However, I would argue that other languages (not just limited to
Rust) have issues calling functions that require a pointer to
non-generic objects and essentially require a redefinition in their own
language.

I don't see a problem with this.  It seems very self contained.

We're sending this series as RFC because there is remaining work
we'd like to do, but we'd like to get early feedback on this approach,
and particularly to ask for advice on a few topics:

* alternative methods of exposing only a subset of symbols in our
  library

We should probably support symbol versioning in the libgit_ code on
supported platforms if we're going to expose it.  Otherwise, we're
setting ourselves and distributors up for a world of pain when we change
the ABI, such as when we add error handling.

* bikeshedding on the name (yes, really). There is an active, unrelated
  CGit project [4] that we only recently became aware of. We originally
  took the name "cgit" because at $DAYJOB we sometimes refer to git.git
  as "cgit" to distinguish it from jgit [5].

* gauging the level of interest in calling Git code from Rust

I left some comments in the series.  I think this is a nice first step
as a proof of concept, and I'm very pleased to see it.

If your goal is to simply expose C APIs, I suggest calling it something
like cgit-sys, since the -sys suffix is customary for wrappers of C
libraries.  If your goal is to provide actual wrappers that people will
use in real Rust code, then I think that we should _not_ expose the C
API, since most Rust users will not want to use that.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA