Coping with different versions of AMOF standard#26
Conversation
agstephens
left a comment
There was a problem hiding this comment.
@joshua-hampton: this looks like a straightforward and sensible approach.
On the issue of whether you have a mechanism to go and look for versions that are not found:
- if that is easy to do then you could try it
- but, installations might exist where the
usercannot write to the installed version ofchecksit - so, a fall-back could be "please talk to your Admin about getting version {version} installed (if it exists)"
|
@joshua-hampton , when you have finalised this change and merged it, let's increment the version of |
|
I think I have implemented this. In check.py, upon discovering the file in question is an NCAS-AMOF file, checksit will:
A couple of exceptions explicitly caught and raised:
To help this work, In doing this, I also discovered that some of the vocab and spec files I had were different than what would be made for v2.0.0 in this method. I had files that I had downloaded myself from the spreadsheets when testing that code, presumably the sheets had been changed since the release version in AMF_CVs. I have updated the ones in checksit to match the v2.0.0 release in AMF_CVs. |
agstephens
left a comment
There was a problem hiding this comment.
@joshua-hampton: this looks great. Please merge - and I'll install on JASMIN.
Moved NCAS-AMOF specs and vocabs into folders based on standard release version.
When checking an NCAS-AMOF file, checksit:
Changes also to make_specs.py:
version_numberas a parameterf"checksit/vocabs/AMF_CVs/{version_number}"and writes specs tof"specs/groups/ncas-amof-{version_number}"Could include call to make_specs, and some code that pulls the vocab CVs from github, from checksit/check - if standard version identified isn't present in checksit, go looking to see if we can make the specs?