tonimelisma
commented
3 years ago To quote the great John Cupitt himself, check out: https://github.com/libvips/libvips/issues/1929#issuecomment-744061139
The varargs stuff basically makes C type unsafe. Managing the specific libvips version dependency is a pain, not to mention adopting new functions. We get issues raised as people are using different environments and they run into issues. As you can see from the errors in golden tests today, the Github CI pulls in the vips version of the day from homebrew (it's not pinned) so basically we're supporting whatever libvips version homebrew offers at the moment, and when it updates, like it did today, CI breaks. Not sure if pinning is the answer either, probably we'll just have a floating dependency because that's what most users likely use as well.
Using the lower level GObject API everything would be type checked at runtime, and the GObject introspection would automatically make the full API available (whatever the version). So that's kind of the recommended way of actually doing a Go library for libvips.
However I don't think there's proper GObject (or glib/gtk/whatever) Go libraries, there's one gtk3 library last updated 2012. And I'm pretty sure whatever code we could create wouldn't be very idiomatic Go. In any case I think it's 100% sure it wouldn't be backwards compatible.
But you know David, at the end of the day it's just us two guys hacking at this, so we I don't think we have major manpower for a rewrite. I'm not sure about the benefits of actually doing a rewrite, whether it's possible with GObject in Go and whether we could create a great Go library based on the GObject introspection approach. I work with enterprise stuff in my day job so I've kind of learned to like technical debt and "good enough" solutions. Plus whenever a user needs a function that's missing, they put up a PR. They get the joy of contributing and what not. Test coverage is over 80% so it's easy to see nothing breaks in a major way.
I kinda like it as it is but as said I'm not a purist, I'm more in the "rough consensus and running code" camp.
davidbyttow
In the original version of libvips, the operations were mostly all code-generated by querying libvips library. It seems like we could do this again to stay in sync with libvips, as it could handle generating functions such as:
I understand why we moved away from it originally, but now I'm reconsidering something more robust. Any thoughts here @tonimelisma or should I just look at it again and propose something if it makes sense?