Support for choosing a jsonschema.validator

[tysg]

jsonschema's CLI mode has a -V option to specify a jsonschema.validator. As that CLI mode is deprecated in favor of this repo, can we also introduce a similar option here?

https://github.com/python-jsonschema/jsonschema/blob/16fef5b641e82a88f71f50657e29ae8a827969a5/jsonschema/cli.py#L188

[sirosen]

Before introducing this just for parity's sake, I'd like to understand:
Is there a particular use-case that you have for this flag? I would expect that schemas containing $schema get the validator they want anyway. So I'm not sure what the purpose is behind being able to specify a validator other than the one specified by the schema.

I'm not against adding this, so long as I understand why it's wanted first.

[tysg]

Thank you for the response. I came from ahrefs/atd#338. atd generates JSON schema and uses jsonschema to validate whether the generated schema is backwards compatible. See this commit where it adds checks for a previous schema standard.

[joestump]

@sirosen we use check-jsonschema to validate config files for our custom in-house automation tooling. I have a need wherein I need to enforce more custom validations on these config files, which are not supported by the community specification:

1. I want to error out when certain values are given to a list. The possible values are too many in number to use an enum. This is not possible with the current specs.
2. I want to error out when certain values are given to a list and another value is set to something incorrect. Also not possible with the current tooling.

In theory, I could use a custom validator as @tysg has pointed out, but it'd leave me re-implementing this CLI and/or calling it before/after check-jsonschema.

[sirosen]

I'm convinced of the utility of this (it didn't need much 😁 )!
I need to think a little more about the interface, though it will probably be very similar to what existed in jsonschema.

As an aside, this may also make me rethink my stance a little bit on the kind of packaging and installation scenarios which are supported -- if you need check-jsonschema installed in a virtualenv with your own package (which defines its own validator class), then the dependency constraints for check-jsonschema probably need to be looser.

It will be a few days at least before I can carve out time to work on this, but it shouldn't be terribly complex once I get to it.