@Freed-Wu another advantage I can think of is user don't need to run compile step when using FFI. With normal lua binding, a compile step must be done to compile C binding header.

And I designed this lib with LuaJIT in mind first :(

user don't need to run compile step

Luarocks allow distribute compiled binary rocks (lua bindings for libgit2) so it shouldn't be a problem except they use unusual OSes 😄

Another case is in some OSes, the libgit2's path is not fixed. Such as NixOS's /nix/store/qra2k11wd0pzwbsqraml3y57v6gy37ys-libgit2-1.8.1-lib/lib/libgit2.so. If we let user config it, it will be a little troublesome. However, build it as a lua module can write the path to dynamic link library's rpath to save user's config. such as:

$ ldd ~/.local/lib/lua/5.1/tellenc.so
	linux-vdso.so.1 (0x00007fea683bc000)
	libstdc++.so.6 => /nix/store/22nxhmsfcv2q2rpkmfvzwg2w5z1l231z-gcc-13.3.0-lib/lib/libstdc++.so.6 (0x00007fea68000000)
	libm.so.6 => /nix/store/3dyw8dzj9ab4m8hv5dpyx7zii8d0w6fi-glibc-2.39-52/lib/libm.so.6 (0x00007fea682c9000)
	libgcc_s.so.1 => /nix/store/22nxhmsfcv2q2rpkmfvzwg2w5z1l231z-gcc-13.3.0-lib/lib/libgcc_s.so.1 (0x00007fea682a4000)
	libc.so.6 => /nix/store/3dyw8dzj9ab4m8hv5dpyx7zii8d0w6fi-glibc-2.39-52/lib/libc.so.6 (0x00007fea67e09000)
	/nix/store/3dyw8dzj9ab4m8hv5dpyx7zii8d0w6fi-glibc-2.39-52/lib64/ld-linux-x86-64.so.2 (0x00007fea683be000)

for the use case of Nixos, because library path is not standard, for luagit2 to work, you have to compile lua binding when installing plugin. Then it defeat the orignal purpose of a compiled binary distributed via luarocks (that you suggested in previous comment).

Yes, Nixos is one of unusual OSes 😄