version 1.2 about pact-specification

[ceddlyburge]

Hi Neil, that makes sense and I don't think I'd be keen in your position either. You make a good point that the released PACTNet will cause errors, so even if somebody was using this by mistake we would find out pretty quickly. If I ever find myself with some time I'll take a look at those version 2 matchers.

[uglyog]

This doesn't seem to require a specification change, just an implementation detail which language implementers can do.

I also don't see how this would work with nested objects in the body, they will not be compared if the values are skipped.

[neilcampbell]

@ceddlyburge The only reason this has not been done in Pact-Net is that I personally don't have the time. I have actually done most of the refactoring to support v2, it just needs matchers and a whole heap of matcher validation. Have you had a look at the version-2 branch?

As mentioned in the PR, the beauty of open source is that you can fork and use a custom version which satisfies your needs. Personally I think this is the best option at this time, unless of course your are keen to help with v2?

[ceddlyburge]

Hi Neil

I'm not trying to get on your back about this, so apologies if it looks that way. I completely understand the lack of time argument, and am in the same boat myself.

Implementing the version 2 matchers looks significantly hard to me (maybe I am missing something), and I already have something that suits my purposes. I am not planning to do this, but if I were, I think it would take me many months to finish, and as mentioned, I already have something that works.

A new PACT minor version is not a necessary thing, being as I will keep everything in house, but it would be useful. For example, if somebody in my company mistakenly installs the official PACT net, instead of the one we have made, it would be nice if it rejected the new format PACT, at which point we would realise and do something about it.

Ronald, the specification change is because a client / consumer can specify whether it wants to ignore values or not, please see the snippet below. I think the code does work with nested objects, but will need to check this.

 "interactions": [
    {
      "description": "A GET request for the yield",
      "provider_state": "The yield I'm asking for exists",
      "request": {
        "method": "get",
        "path": "/api/v1/Yields/fGERdev001",
        "headers": {
          "Accept": "application/json"
        }
      },
      "response": {
        "status": 200,
        "headers": {
          "Content-Type": "application/json; charset=utf-8"
        },
        "body": {
          "Enet50": 1.0,
          "Number": 1,
          "Enet75": 1.0,
          "Quality": "1",
          "ProjectID": 1,
          "YieldType": "1",
          "Description": "1"
        }
      },
      "valueAgnosticBodyComparison": true
    }
  ],

Cheers

Cedd

[neilcampbell]

@ceddlyburge Nah not at all, completely understand where you are coming from.

The issue with merging it into the public repo, is that I now take on support (maintenance, bug fixes, backwards compatibility etc etc). So whilst your intention is for you to only use it, other people will also start using it. Given that it is a concept that will be superseded by v2, I don't want to take this on.

For the accidental upgrade scenario you mentioned, on the consumer side you will see a compile failure. On the provider side the Pact verification test will fail, as the values will not match. So yeah I don't actually think you will have an issue there (other than the failure not pointing at exactly what is wrong).