Tool API spec update: don't show tools that have no data

[yochannah]

Some tools, such as the Protein Atlas expression tool, only work with certain data sets from certain mines. See https://github.com/intermine/bluegenes-protein-atlas-tissue-expression-visualizer/blob/master/src/queryData.js#L6 for an example

• [ ] We should figure out how to make bluegenes look for certain data entities in the model and only try to load the tool if it is compatible with a given intermine.
• [ ] release version 1.1 of the spec
• [ ] make sure tools can specify which version of the spec they comply with
• [ ] update all tools, yowza.

[heralden]

Looks like we can confirm whether the mine model supports it by checking the keys in :assets :summary-fields mine in appdb. Should we simply add a field to config.json, perhaps called model, which takes an array of these strings? (eg. ["proteinAtlasExpression", "atlasExpression"])

[yochannah]

This sounds right! It should probably be full paths, though - e.g. Gene.proteinAtlasExpression or ProteinAtlasExpression

[heralden]

I ended up calling it depends, and with the elements specified as ProteinAtlasExpression like you suggested.

It will be a non-breaking change, since the tools that need this feature can add the depends key while those that don't will work like before. Do we need to version the tool api in that case?

[yochannah]

I love non breaking changes!!! Let's version it anyway - semver principles suggest this should be a minor version or even a patch since it's non-breaking https://semver.org/

On Tue, 20 Aug 2019 at 15:42, Herald notifications@github.com wrote:

I ended up calling it depends, and with the elements specified as ProteinAtlasExpression like you suggested.

It will be a non-breaking change, since the tools that need this feature can add the depends key while those that don't will work like before. Do we need to version the tool api in that case?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/intermine/bluegenes/issues/382?email_source=notifications&email_token=ACGXRDT46ZIJPP2FX7KB3XTQFP7D3A5CNFSM4IIR4B6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4WQ63I#issuecomment-523046765, or mute the thread https://github.com/notifications/unsubscribe-auth/ACGXRDRGCEPD7Q5STQHB2ZLQFP7D3ANCNFSM4IIR4B6A .

[heralden]

According to semver we should be at 2.2.0. Since there have been three changes to the tool api, from my recollection:

• Removing support for formats "list" and "lists" (definitely a breaking change)
• Adding depends key (not a bug fix, but a backwards compatible feature)
• Navigate function (another backwards compatible feature)

We only have one tool that used "list", (https://github.com/intermine/bluegenes-GO-term-visualizer) which I'll fix once I can fix https://github.com/intermine/imjs/issues/52.

Now I have some questions. How are we going to release version 2.2.0 of the tool api? Is it enough to hard-code the version number somewhere in the bluegenes tool code, or should we also keep a changelog and link to it in the docs?

To do it properly, we would also have to update the config.json of all existing tools (and the tool generator) to specify apiVersion: 2, as any missing the key would be interpreted as supporting only 1. (Obviously it would only be necessary to specify the major version number, since the other two are non-breaking.)

[heralden]

After a talk, we decided to simplify this change to only create a Tool API changelog with notes on the non-breaking 1.1 update with:

• Adding depends key
• Navigate function

The reasoning being that bumping a major version and thereby requiring to check each tool's apiVersion and handle the case where they're outdated, would be too much effort at this early stage.