On 2024.08.07 22:03, brian m. carlson wrote: > 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. I'll be very interested in seeing this, please CC me. > > 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. Symbol visibility and versioning are both areas I'm not very familiar with. I'll do some homework but might need additional help later on, so please keep an eye out for beginner mistakes I might make in later versions. > > * 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
