New Extension Registry: validation of extensions.csv

[odscjames]

This is a spin off from #90

Note this includes validation that can be done on extensions.csv only - there is additional validations we can do on other files but that's a different issue.

Currently there is the following validations applied to extensions.csv

• id is unique
• repository_url starts with https://github.com/

What other validations could be applied?

• id is all alphanumeric or underscore only
• repository_url is of pattern https://github.com/XXXX/YYYYY
• a category is set
• a category is set and it is one of an approved list only (could store approved list in new file categories.csv?)
• core is a string which is a boolean value "true", "1", "false", etc - so leaving blank or writing "cat!" would fail (currently blank would be silently changed to false)

As for the method of applying validation, currently validations is done by throwing an exception in ocdsextensionregistry/validate.py or in the validate_extension_registry_data_only method of ocdsextensionregistry.models.ExtensionModel. In ocdsextensionregistry/tests/test_validate.py there are pytests that are already run by Travis.

We could develop new validations directly in Python, or we could also try the technique of converting a line to a JSON and then using JSON Schema. I suspect that in many cases Python would be the simpler or more powerfull route but I note that both can by tested by pytest in the same way as current validations. The important thing is to agree on the criteria - as long as there are some tests I'm not to fussed about the technique.

[jpmckinney]

I prefer using JSON Schema (restoring parts of entry-schema.json), because we use JSON Schema everywhere else, and it's straight-forward to re-implement (use a DictReader and then validate each row with a JSON Schema validator, as done here), rather than doing some bespoke Python methods.

Also, we should be strict about the format of booleans (true or false). There's no need to support a wide variety or truthy or falsy values – and we can remove the utility code that implements that flexibility.

@odscjames Is this something you can take forward in the short term?

[odscjames]

Can I just confirm criteria - all the points I listed in "What other validations could be applied?" are things you think we should be doing?

[odscjames]

Also is there any other criteria you can think of to add to that list?

[jpmckinney]

Yes, the validations should be as strict as possible - I may think of other criteria once I see a PR. However, at a later time, we will want to relax the dependency on GitHub, so we don't need to validate GitHub URL formats.

[jpmckinney]

Closed via #99 🎉