Re-implement Pact Broker Client in a language that can be compiled to a standalone binary

[canny]

The packaging tool that we currently use to share the Pact binaries is no longer supported, and creates a package that is very large. It also has issues on Windows due to long paths. Using a language designed for compiling standalone binaries would create a better experience.

Requirements:

• Needs to be supported on windows, old mac, new mac, linux and the standard linux Docker flavours (alpine) (TODO clarify these)
• Should be able to implement the same flags as the current CLI (eg. multiple flags with the same name, ordered groups for can-i-deploy)

Potential languages:

• Rust (already have rust in the ecosystem, but not many people know it)
• Go (lower barrier to entry, but is a bit lower level than we really need)
• Crystal (not sure about windows support)

https://pact.canny.io/admin/board/feature-requests/p/re-implement-pact-broker-client-in-a-language-that-can-be-compiled-to-a-standalo

[canny]

This issue has been linked to a Canny post: Re-implement Pact Broker Client in a language that can be compiled to a standalone binary 🎉

[YOU54F]

Beth - January 18, 2022

I'm actually not 100% convinced that we should re-implement the CLI, if we can find another way to distribute the code for people who can't use Docker and can't install Ruby on their system.

While there are benefits to distributing completely standalone packages, many other CLIs require you to install a particular language to run their CLI, presumably because scripting languages are more productive to write in, compared to languages that can be compiled to binaries (Rust, Go). The AWS CLI, which must be one of the most widely used CLIs in existence, requires that you install python. The travis gem requires you to install Ruby. Many other tools require you to install Node. It is not unreasonable to distribute a CLI as a package for a particular language.

If we were starting from scratch, Ruby would not be the language chosen now, but we do already have a well hardened, stable CLI implementation in Ruby, and while every developer likes to re-invent a wheel, I don't think it's the best use of our time at the moment.

Addressing the Travelling Ruby issue and finding another way to distribute the package for non-ruby users would, imo, be a better use of our time. There are several alternatives to Travelling Ruby - I just haven't set aside the time to investigate them yet, as there have always been higher priorities.

[YOU54F]

Matt Fellows - January 18, 2022

I think it's also worth making mention, that the backwards compatibility with the pact broker built into the current CLI would need replicating. I'm not sure what this would translate to effort wise, but is a key consideration.

[YOU54F]

cspengl - January 25, 2022

Hi folks, I really like this idea. I recently found myself in the exact situation you are describing. I was looking for an easy way to just download the pact broker cli as a standalone executable similar to how I can install kubectl for kubernetes.
Looking towards widely used CLIs like kubectl, docker-cli or helm which perform very similar tasks, especially Golang sounds like a good option to me.

Matt Fellows - January 25, 2022

cspengl: thanks. Can you please elaborate specifically on the issues you experienced when using the standalone CLI (see https://github.com/pact-foundation/pact-ruby-standalone/releases)?
(not discounted that you had issues, but looking for customer feedback here).

[YOU54F]

I've been slowly chipping away at this off and on

https://github.com/YOU54F/pact_cli