Third-party Go dependencies in early preview

[ivov]

Lisette projects can now depend on third-party Go modules, in addition to the Go stdlib.

Shipped with lisette-0.2.2 as early preview.

Two new commands:

• lis add <module> adds a third-party Go module to your Lis project.
• lis sync keeps the lisette.toml manifest in sync with your Go imports.

lis add go.uber.org/zap

✓ Added go.uber.org/zap v1.28.0
  └─ go.uber.org/multierr v1.10.0

See the new docs section and CLI help at lis help add and lis help sync

This early preview was tested against a good portion of the API of 50 popular Go modules. Go has a vast ecosystem, so you will find that some third-party Go modules may not be fully supported yet, e.g. libs that exercise type features Lisette does not model yet, or rough edges in typedef generation. As always, your feedback and findings are welcome.

[ekisu]

Are there plans to support CGo-reliant dependencies? I tried using miqt as a dependency and, by default, the generated typedefs only contain an UNLOADABLE error.

I noticed that the bindgen code does set CGO_ENABLED=0; removing that seems to kinda work? Although the generated typedefs are a bit rough for constructor functions, always returning Option<Ref<T>>:

lisette/bindgen/internal/extract/extractor.go

Line 73 in 13a3231

return append(env, "CGO_ENABLED=0", "GOFLAGS=-mod=mod")

[ivov]

Thank you for raising this.

I initially deferred cgo thinking it'd need additional interop work, but just now I smoke-tested many libs with cgo enabled and they all work out of the box, e.g. mattn/go-sqlite3, DataDog/zstd, gopacket/pcap, go-gl/glfw, ipsn/go-secp256k1. Therefore I decided to enable cgo at #760. I do expect gaps but let's see where the long tail is.

Also, your miqt constructors issue is unrelated to cgo. Bindgen has a nilability check that was being overly conservative, fixed at #761. Please give it a spin with lisette-v0.4.3 and feel free to open an issue if you find anything.