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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Aug 7, 2024, 22:03 UTC
Message-ID: <ZrPvSWoUOEaUIjWq@tapette.crustytoothpaste.net>
In-Reply-To: <cover.1723054623.git.steadmon@google.com>

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.

Show 7 quoted lines

> 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.

Show 6 quoted lines

> 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.

Show 6 quoted lines

> * 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