Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add --validator-class option for passing a validator class #327

Merged
merged 5 commits into from Sep 20, 2023

Conversation

sirosen
Copy link
Member

@sirosen sirosen commented Sep 20, 2023

  • Add interface for passing custom validators
  • Instrument use of custom --validator-class values
  • Restrict --validator-class to types (no functions)
  • Add tests for custom validator usage
  • Add doc section covering --validator-class

The basics are all here, and this should resolve #262

For users seeing this, and for comparison with the old jsonschema CLI
feature, I have a few notes on the interface and some related topics:

  • --validator-class is the option name (there is no short opt)

  • The syntax for specifying this is slightly different from --validator in
    the old CLI -- you must separate your module name from your class name with
    a colon, as in foopkg.barmodule:MyValidator.

    • This could be loosened to the purely dotted notation if there's a strong
      argument for doing so, but the interface is simpler and cleaner with this
      syntax, so please think critically about whether or not it's important
      before asking for it to change.

    • As an example usage,
      --validator-class 'jsonschema.validators.Draft3Validator'.

    • There is no special case for the jsonschema builtin validators

  • check-jsonschema has a few features which expect the validator class to
    be built only using the documented jsonschema interfaces. In particular:

    • --fill-defaults uses the extend API to modify the validator class
    • a referencing registry is used (rather than RefResolver) and is passed
      on init
    • a custom format checker is passed on init, and it is not derived from
      FORMAT_CHECKER on the --validator-class value
  • Usages may change over time as jsonschema and check-jsonschema continue
    to evolve. Barring major issues, I do not intend to treat incompatibility
    between a custom validator class and check-jsonschema behaviors as a bug.

  • The above stated, if check-jsonschema is doing something outside of the
    jsonschema API contract and it causes issues with a custom validator, that
    is a bug; please report any of those and we can get them fixed. :)

  • Within the scope of this change, no change is being made to the dependency
    bounds being applied by check-jsonschema. There will probably be some
    measure of change to make it easier to control dependency versions used, but
    check-jsonschema also has pre-commit hook usage to consider, with its own
    implications about appropriate dependency specification

  • check-jsonschema currently will not call check_schema when using a custom
    validator class (please open an issue if you would like this to change; it is
    a point of flexibility based on user demand)

  • The CLI validation currently requires that the value be a type, meaning it
    typically has to be a proper python class. The possibility of some callback
    or alternative extension point is open if a well-reasoned proposal for some
    secondary behavior can be made.

  • All of the decisions being made here about the interface, implicit API
    contract, and expectations are subject to change if there's a good reason.
    After all, this is an advanced feature for "power users".

This adds the necessary pieces for passing a custom validator class to
check-jsonschema. `--fill-defaults` help text contains a hint that it
may conflict (depending on the validator), to help warn of the
potential for surprising interplay between a custom validator class
and optional check-jsonschema behaviors.

This commit only adds the interface pieces for passing the validator
class to the CLI in a well-specified format, and handles the
import/load of that value. No implementation in terms of threading the
resulting value down to the validator(s) is included yet.
Implement the underlying arg-passing to set the `--validator-class`
from CLI arguments when creating a SchemaLoader (the class used
when `--schemafile` is used).
In order to better guarantee that `--validator-class` provides the
name of a `jsonschema.protocols.Validator` class, require that the
value passed is a type and not an alternative function.

This requirement does not lose significant expressive power and allows
us to more safely assume that the validator really is an
implementation of the protocol which can be extended with
`--fill-defaults` and other validator-related hooks.

There is no real way to guarantee the safety of using the user's
Validator. After all -- it could always raise an error at any time --
but this matches check-jsonschema's expectations about the argument
better.

This change can always be reverted in the future if there is
significant demand for a function-as-a-validator-class option.
Using the mock_module fixture (lifted to top-level conftest), setup a
custom validator which does some "real" validation work.
@sirosen sirosen merged commit 8bd3492 into main Sep 20, 2023
39 checks passed
@sirosen sirosen deleted the allow-specifying-validator branch September 20, 2023 03:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for choosing a jsonschema.validator
1 participant