Feat/purego

[YOU54F]

fixes #452

[coveralls]

coverage: 30.702% (+2.4%) from 28.272%
when pulling 12f1871 on YOU54F:feat/purego
into a3205d4 on pact-foundation:master.

[YOU54F]

We could use pact-go bin to download the library, and act as a runner wrapper over go test, which sets the env var to the shared library, wherever the user has installed it.

the install and run could be wrapped so if we can find the shared library, it asks the user to install it

This will remove the need for sudo

we would also create arch specific golang packages for each arch/plat if poss (would that need seperate repos)

[YOU54F]

Okay, so this is pretty neato now.

pact-go install will default to ~/.pact/pact-go/libs

the config file in ~/.pact/pact-go.yml now contains a path to the libDir

pact-go test provides a wrapper around go test which

• reads the location of the libDir from ~/.pact/pact-go.yml
• sets the expected PACT_LD_LIBRARY_PATH env var
• if it can't read the config, it defaults to trying to read PACT_LD_LIBRARY_PATH env var
• if not it errors

Users can still use go test as usual, with the caveat, they need PACT_LD_LIBRARY_PATH set in their shell

No special paths are required, and we don't need to code them directly into our source code, they don't need to be well known paths, for library loading on macos, with sip enabled, so no sudo required 🎉

➜  ~ csrutil status
System Integrity Protection status: enabled.

The only reservation is the purego project is still in beta, but with everything passing in our suites, I think I would still go for it, for the simplified developer experience.

[YOU54F]

This takes the approach

• Utilise ebitengine/purego in both CGO_ENABLED=0/CGO_ENABLED=1

with no fallback to the existing cgo mechanism to avoid code complexity