RFC: Replace cgo with ebitengine/purego

[YOU54F]

Rationale

since pact-go v2 was created, we rely on functionality from a rust shared core, which is delivered by way of C shared library, and is loaded via FFI (Foreign Function Interface) via cgo, into pact-go.

This has meant that users have to explicitly enable cgo, and those who cannot install or do have a c compiler installed, have been unable to use pact-go v2.

See #321 for a related issue.

Alternatives

1. Rewrite pact-go in purego (not unfeasible, but highly undesired, and moves away from a single shared core mantra)
2. Leverage ebitengine/purego - A library for calling C functions from Go without Cgo.

Leveraging ebitengine/purego

Options

1. Utilise ebitengine/purego in CGO_ENABLED=0 mode only
2. Retains standard cgo behaviour owned by the go team
3. ebitengine/purego is in beta, so this uses a cautious approach
4. Utilise ebitengine/purego in both CGO_ENABLED=0/CGO_ENABLED=1
5. Consistent user experience in both modes,
6. No need to maintain two sets of code CGO_ENABLED=0
7. ebitengine/purego is in beta, so this uses a everything passes in CI approach (and we hope someone continues to maintain ebitengine/purego in the future)

End users experience

Currently users need to

1. Ensure CGO_ENABLED=1
2. Ensure they have a CGO compiler
3. Ensure they have installed the pact-go shared library
4. Ensure the shared library is in an known place for CGO linking (hard coded in pact-go)

With ebitengine/purego, the user just needs to perform 3, and in step 4, they can point pact-go at wherever the shared library lives with no restrictions. This means it can be in non-standard paths, different versions could easily be managed.

Due to size reduces in the native libraries, we could possibly include the shared libraries in the code base. it would inflate the git history, but would make it very easy for uses to just plug and play with pact-go

[spockz]

We are currently using the pact-jvm implementation and in the process of migrating our codebase to Golang. pact-go forces us to use CGO which is otherwise unnecessary and also undesirable. Dropping CGO as a requirement would be very useful for us.

[YOU54F]

The purego project is still in beta, and cgo is officially supported by the golang team.

What does your team do in situations where they require cgo functionality, or programs with cgo functionality (bearing in mind this is test, not production code). Is there a blanket ban, or would you seek to rewrite in pure golang.

pact-go isn't forcing you per sai, it's just a the official mandatory pre-requisite of building any project in golang, which requires bindings to a c language. I wish cgo and the golang project, had a better delivery mechanism for golang based projects, which deliver c bindings via cgo, but alas, we are where we are. It's why the pact-go project requires an install step in pact-go v2, which is probably suboptimal from a newbie users perspective.

I would like to provide a fallback, for non cgo users such as yourself and especially for windows users where cgo is an inconvenience to setup and use with pact-go, but I can also see a case whereby a user may want to use the non-cgo bindings of pact-go, but still rely on cgo based features in a test suite, such as golangs race detector (which enabling, seems to be the general recommendation when testing with go)

references for the race detectors libc/cgo dependency

• runtime/race: eliminate dependency on cmd/cgo golang/go#6508
• runtime/race: eliminate dependency on libc golang/go#9918

So we may want to support use cases of

• cgo disabled - use pact-go via purego(beta)
• cgo enabled
  • use pact-go via cgo(standard)
  • use pact-go via purego(beta)