Accept version as a parameter for old version support about reasoner-validator HOT 4 CLOSED

Yeah, handling versions here is tricky.
There are a couple reasons we chose to fix each release to a specific TRAPI version.

1. This keeps the package as lightweight as possible. We don't have to include every historical TRAPI spec or GET them at run time (reasoner-validator works without an internet connection).
2. The TRAPI components sometimes actually change names between versions. Since our functions are named after the TRAPI components, it seems strange to allow specification of the version with each function call.

Now, if we were to restructure our API a bit, these objections could carry less weight. Something like jsonschema's IValidator interface might would be better.

from reasoner-validator.

Thanks Patrick for the feedback.

Regarding item 1, the package you build is already super duper light weight, and you've released only a few versions which mainly only change the .yml file schema. Since your function signatures are all dynamic anyways, then it seems feasible to just accept schema_version="something" as an argument to the validation. A few .yaml files that are 33KB is nothing to my build. Even if you had 100 of them.

Regarding item 2, same point about dynamic function signatures. Our intellisense can't pick it up, anyway. Seems like this would work if the validation object and the schema are both passed, then it would solve both of those problems.

For example, something like:
reasoner_validator.validate_Response(myResponseObject)
would become
reasoner_validator.validate(validationObject=myResponseObject, validationType="Response", validationSchema="1.0.2")

Right now, my intellisense doesn't help me at all as you can see here:

from reasoner-validator.

All good points. And avoiding hitting the internet is kinda silly for 1) any PyPI package and 2) especially one meant for validating REST API payloads.

It's a bummer that intellisense doesn't work. What does work with the dynamic function generation is the sphinx autodoc. I was having a bit of fun there, but a well-documented bad API is still a bad API.

So we're talking about a substantial change, but it should make the package more usable and actually easier to maintain in the future. I'll make a 2.0 branch.

from reasoner-validator.

For our stack, we are versioning our api through the router like /v0.9/ /v1.0/ and /v1.1/.

So its all the same source code, infrastructure, cicd, container, etc. So we cannot install 2 versions of the same package (your package).

So we have resorted to copy your source code for reasoner_validator 1.0 and pasting it in statically, and then install from github for the latest 1.1.

from reasoner-validator.