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
Attachment:
signature.asc
Description: PGP signature
