What is the thoughts on required pact-plugins being auto-installed by the Pact client libraries. Should 1. This be the preferable approach a. Should we allow configurability as to where the

PACT_PLUGIN_DIR

should be. 2. We allow the user to disable auto installation a. We allow the user to specify their own path to

PACT_PLUGIN_DIR

Thoughts come from https://github.com/pact-foundation/pact-php/pull/330 I believe the following libraries with self load plugins • pact-rust • pact-jvm • pact-php v10 alpha Happy to be corrected on the above

The main concern was running in very strict corporate environments, where you couldn't download the plugins and you may not have write access to the home directory. So they could pre-setup a plugins directory somewhere else.

I still think the package managers could / should be used for this. Pact makes a "publish plugin" tool. It makes packages for all of the main pact ecosystems, which just wrap up the plugin into the package (possibly with some wrapper code if the Pact client lib needs it). As a plugin maintainer, you'd publish the packages made by this tool. Each Pact client lib would know (by convention) how to unwrap the plugin from that package. So you'd require the specific plugin's package for your language, then in code do something like:

pact.loadPlugin("somePluginPackage")

and the Pact client lib (eg pact-js) would read that package, unbox the plugin, and load it.

Pact makes a “publish plugin” tool. It makes packages for all of the main pact ecosystems, which just wrap up the plugin into the package (possibly with some wrapper code if the Pact client lib needs it).

you could raise this request it at pact.canny.io Tim 😉 It’s a good idea, possibly, but not an easy one to achieve.

I think my proposal is starting smaller- as in, you’d have to do very little. The existing strategy means implementing package management and reasoning about plugin dependencies

Can you perhaps explain? Taking an example, we have a community member who has created an Avro plugin. They wrote it in Java (actually, Scala) but it runs on the JVM. This plugin can be distributed to any language. If we wanted it in NPM, would we need to create an NPM package to wrap it?

Yes, that’s right. There’s an explanation above, unless you’re saying that it’s not clear from that?

Pact makes a “publish plugin” tool. It makes packages for all of the main pact ecosystems, which just wrap up the plugin into the package (possibly with some wrapper code if the Pact client lib needs it).

This? If so, I agree that’s a nice experience, I’m just making the point that that’s a non-trivial amount of work, and definitely more than what the CLI has to do. I think your point though is that we may end up going a registry path, which would introduce a different line of complexity?

I think it’s strictly less work than the current approach. Although maybe that’s already built, so it doesn’t matter

true. I think it’s a good idea though and will put a feature request for it. I’m currently thinking about how we do “roadmaps” at the moment, but I don’t have any views so it’s just going to go in canny and perhaps with a tracking issue on pact-plugins repo

I like the general test that plugins should make Pact simpler

My Immediate thoughts about the directory stuff • What if we can’t write to the default

$HOME

location (

$HOME/.pact/plugins

) ◦ Pact-plugins support reading a non default location by setting

PACT_PLUGIN_DIR

• What about libraries which store required things within its own folder ◦ PHP uses a bin folder On the plugin side, currently I've been interacting with the pact ffi lib through client library wrappers and download the required plugins with a cross platform

pact-plugin-cli

tool I was kinda thinking it would be nice if the pact_ffi could just go and make a request to get the required plugin, so the user doesn't have to know about it, and as a library author, I don't need to package seperate packages, I just the ffi and it takes care of it. That comes back to the problem of • plugins being downloaded after the pact library is installed • plugins being downloaded during a test (how do you know which plugins you need up front) Maybe that is okay for most users, they would download once and be stored. If you needed to download them prior you could use the pact ffi which functions into the pact-plugin-cli to allow a user to easily allow downloading of required plugins prior to a test, and can store them somewhere accessible to their code. I had a fleeting thought at the weekend about could the pact rust could be made extensible, so a user could easily build a new matcher or some kinda functionality, and bolt that into the pact core, rather than communicating via the plugin framework over grpc. Not sure of the best experience here, and its tricky as some places are locked down, most people don't want the element of surprise, some people just want to write a test run it and everything be automagic

build a new matcher

Yes, this is the design I preferred

I think at the most part it doesn't make the concept simpler at the moment, but affords the capabilities to users. It's on us to really sharpen that user experience (and conversely the maintainer experience) through the docs and the critical journeys to what the hell is what, whats it's capabilities and why the hell would I need plugins. I'm just on a mission to get pact-python and pact-ruby to some element of ffi support and then its a big lens on the doccos. I am really love async apis work so have some lessons to take from them

I had a fleeting thought at the weekend about could the pact rust could be made extensible, so a user could easily build a new matcher or some kinda functionality, and bolt that into the pact core, rather than communicating via the plugin framework over grpc.

they could do that now, to be fair. The thinking - and really, evidence - is that getting contributions into the core (both Ruby and Rust) has been too much of an ask for people in the past. I have no doubt that if we spent some time thinking about it and making it as easy as possible, that we could increase the number of contributions. Matchers are a good example I think, because they are much narrower in scope. gRPC for example and Avro involve a lot more complexity, and asking someone to write it in rust instead of their preferred language, is a tall order. It also bloats the core a lot - plugins mitigate both of those problems.