@Adam Cox @Tien Vo @Ali Ustek we are planning to make some improvements to the plugin interface. This will probably just be a minor update to the current interface, if possible. The place to start would be to let us know what the biggest issues you have had using or building the plugins. One area we are definitely looking to improve is the verification sequence, but this will be the opportunity to make other improvements as well.

For me this feature is in my wishlist: auto download binary and meta files for plugins https://pact-foundation.slack.com/archives/G9VHV9VJ9/p1683866419534919?thread_ts=1683820689.902969&cid=G9VHV9VJ9

The latest FFI should already have that capability.

For me the biggest issue when start using plugin is I can't see its logs, so I really don't know what is going on. For now my understanding about plugins is a bit better so I don't have to read its logs, but I am always afraid of it. Here is the related thread https://pact-foundation.slack.com/archives/C047TCR7B6W/p1679760157876359

In order of importance for us: • Configure interaction to support metadata matching rules. This not working is a pain for us at the moment and is holding us up on making progress without workarounds for one of our providers. • Nested metadata matching. Being able to configure metadata matching at one or more levels deep and ignoring additional keys would also help us configure the metadata in contracts how we want to. • Configure Interaction to support different number types other than double. • Not having to create our own content type to add metadata to contracts. We have had to make the "application/json" content matcher again so that we can add metadata fields into the contract. This means that we have had to find the core implementation of application/json and copy bits of code to keep the same behaviour and then try to add the metadata on top. • Easy to use / documented core library and utility functions for matching. For example a function we can call with a JSON message payload and a pact and find which contract is the best match. Currently we have pieced together bits of pact_matching with our own transformations from a JSON message and some metadata to match websocket messages as they come in. We also reimplemented the loop that goes over the contract and calls the comparison for each one. This process feels like it could be a bit easier for plugin developers if they want a consistent and out of the box feel for the plugin behaviour. • The logging point is a good one. It used to be possible to use RUST_LOG when using the plugin for consumer tests and we would see all of the child_process logs but this seems to have stopped. Being about to log to a file would be nice, capturing any stdout from the plugin process. This would also make the logs easier to read/parse as using the tracing crate in both the plugin and the driver means the child_process lines are quite noisy. Very low priority • Support for downloading plugins from non-open source GitHub repositories • ARM based docker files for building releases. Currently I am spinning up an x86 EC2 in order to compile the Linux plugin builds as the docker images and cross don't play well on my M2 mac. I think most of these are points we have already covered in other threads but if you want more detail or need any clarification from me then I am happy to provide. I am still working on getting our plugin open sourced.

Thanks for the feedback, I'm going to raise some cards in our backlog for these items.