Declaring dependencies

[timgdavies]

One extension may depend on another.

For example, imagine two simple extensions. The first adds an object called 'extension', and then second adds a property called 'subExtension' to this object.

extension_one

{
    "properties":{
        "extension":{
               "type":"object"
         }
     }
}

extension_two

{
    "properties":
        "extension":{
             "properties": {
                   "subExtension":{ 
                       "type":"string"
                   }
               }
        }
}

If you try to use extension_two without extension_one you get invalid JSON Schema, because the information that extension is an 'object' was in extension_one.

Therefore, the extension.json for extension_two needs to declare it's dependency upon extension_one in order to tell applications/validators etc. that they MUST first apply extension_one before applying extension_two.

The question:

• Should the extension.json for extension_two include (a) the extension registry slug of extension_one; or (b) a url to the extension.json for extension_one?

Issues to consider:

• What if a new version of extension_one is entered into the extension registry in which extension is renamed to the_extension? How would a link to the registry slug indicate pinning of versions? Does it need to?

• What if the location where extension_one is available for download changes? Would this require changes to any extensions that have it as a dependency? Or just to the registry?

• What about dependencies between 'local extensions' which don't have an entry in the extensions registry? Do we support dependencies in this case?

• Could there be a mixed approach? Either URL or slug?

[Bjwebb]

It's worth noticing that the example I've come across (https://github.com/open-contracting/extension_registry/issues/41#issuecomment-310041610) is a bit different to the above. In this case, the second extension tries to JSON Ref a building block that is defined in the first schema. I think in general the cases are similar, but the failure is likely to show at a different point in code dealing with it.

[kindly]

@timgdavies I agree with pretty much everything above apart from the fact that the ordering that the extensions are applied does not matter due to the nature of JSON merge patch (it makes no difference if you put the dependant schema first as you are always specifying the whole structure) However, it "could" matter for codelists depending on how we implement applying them.

I think the mixed approach is good. But you only get versioning when using the registry. This is very similar to how pip works. We should allow the option of each extension supplying a version to the registry.

So for example an extension list could look like:

extensions = [
 "location",    # latest location extension compatible with your version of the standard
 "bids==1.1",  # bids extension version1.1
 "enquiries<2", # version of enquiries less that 2
 "http://some.url/extension.json" # a particular extension url (not able to put versions here)
]

So note the versions specified here are the versions of the extensions not the standard. Each should check if the version of the extension selected is compatible with the version of the standard they are trying to extend. If they are not compatible it should be considered a failure. Each extension should specify which versions of the standard they support and if they do not specify it, it is assumed they support any version.

We clearly do not need for all tools to fully support this "yet", but is what we should aim at.

What is an immediate need (to make sure we are future proofing ourselves) is a way to specify to the registry different versions of the extension. There is a separate issue for this.

[jpmckinney]

Let's pursue in https://github.com/open-contracting/extension_registry/issues/56. The template is an unpredictable forum for discussing this.