Remove need for daemon

[mefellows]

Because, it sucks.

The Daemon was originally implemented due to two reasons:

1. We need to install OS and Architecture specific binaries (https://github.com/pact-foundation/pact-ruby-standalone)
2. A lack of 'package management' capability in Golang, as most other languages have - e.g. npm for NodeJS or 'pip' for Python. These package management facilities typically have build or installation hooks that allow us to customise the installation at package retrieval time. In those instances, it's easy to determine the current os/arch and pull in the appropriate

A daemon was a separate install step that decoupled the DSL from this uglyness, in turn creating it's own uglyness:

1. It's painful to Dockerize, as mentioned in Feature request: improve verification error handling when invalid JSON provided #50, as you need multiple processes to run Pact
2. It involves some extra hoops when scripting the Pact tests, as can be seen in our integration tests
3. It makes life more complicated for contributors, having to manage the DSL and service layer abstraction over RPC
4. It's inconsistent with other implementations.
5. It's inconsistent with other go packages - i.e. it can be installed with a simple go get

To work around the limitations and address the issues, these are some options that I can think of:

1. Continue to have a separate 'installation step', but instead of having a daemon that wraps the Ruby binaries, we just install the pact-standalone binaries onto the global PATH. The DSL will then attempt to start the pact-* binaries and fail with a helpful error if it can't find them.

   1. This could potentially be automated via OS package-managers like brew, rpm, curl or chocolatey for Windows

   2. or perhaps could be provided by a CLI step provided by the package itself i.e.

      go get github.com/pact-foundation/pact-go
      sudo pact-go install
      # pact is now fully installed, good to go!
      

2. Remove any installation steps required prior to actually using the library, but have the DSL contain the smarts to fetch the latest standalone package at runtime.
   • This could provide the best 'developer experience' assuming it works properly
   • It might be tricky to implement reliably cross-platform, and could possibly require privileged access to do properly (otherwise hiding binaries in user-space, which can be a source of frustration)
3. Do nothing, and wait for Pact Reference to be completed and go straight to that.

[mefellows]

cc: @zbintliff would appreciate your thoughts.

[zbintliff]

Just a few questions:

Continue to have a separate 'installation step', but instead of having a daemon that wraps the

Ruby binaries, we just install the pact-standalone binaries onto the global PATH
Is this what other libs do?

All for using brew to distribute them.

Do nothing, and wait for Pact Reference to be completed and go straight to that.

Is there a timeline there?

[mefellows]

No, other libs pull in the package dynamically at install time e.g. npm will install the binaries into the node_modules/... directory tree.

No timeline for the reference to be implemented (is ASAP an answer?), although there is a lot of activity in this space.

[bmarini]

I definitely prefer making less assumptions about how the ruby deps are installed and just relying on PATH.

[mefellows]

OK so a working daemonless setup can be found in the feat/daemonless branch: https://github.com/pact-foundation/pact-go/tree/feat/daemonless

TODO:

• Working tests and examples
• Ensure setup/installation notes are clear and easy to follow
• Working Windows/Appveyor build
• Healthcheck feature to ensure library compatible with CLI (as they will now be installed separately)
• Update release page, docs and publish new binary to notify of "deprecation"

TODO list moving to #74, where it will contain the release of several features due to the breaking API change.