Summary

Would it be possible to expose the base_uri passed to the schema reference resolver as a parameter of pyhf.utils.validate?
(and similarly the path used in pyhf.utils.load_schema, too?)

After the proposed change, validate would take an optional argument, defaulting to the currently used path to the package install location, and also forward that path to load_schema, which similarly would take it as an argument (also with a default).
This would make it much easier to validate specs against a custom schema (e.g. one extracted from a reference to the defs.json).

Related problem

When trying to validate components of a to-be-assembled Workspace or Model spec, the pyhf.utils helper functions (validate and load_schema) search for schemas only in the package installation path.
I do not really want to add files to the package install directories manually,
so I cannot use the pyhf.utils helpers to validate partial specs against component schemas (e.g. lumi, sample, or observation specs).

My current work-around

I am currently working around the issue by having copy-pasted implementations of pyhf.utils.validate and pyhf.utils.load_schema in my code,
which I fall back on if the schema is not found by pyhf.utils.load_schema (meaning for everything except Workspace or Model):

try:
  pyhf.utils.validate(...)
except FileNotFoundError:
  homebrew_validate(...) # has a different base path hardcoded in ...

But I feel this is a bit silly (and risks diverging from the pyhf implementation over time)
since the base path to look up schemas in is the only real difference of my copies to the originals.

Additional Information

Example usage after the suggestion is implemented

Validate a custom schema (that is extracted from defs.json or custom-defined) using the pyhf validation helper function:

import pyhf
my_lumi = dict(type='lumi', name='lumi', data=None) # for example 
pyhf.utils.validate(my_lumi, 'lumi.json', '1.0.0', schema_base = 'path/to/local/user/defined/schemas/')

Relevant Issues and Pull Requests

Both of these are more tangential, but maybe there are examples of where this could be a useful feature:

• I guess this change would make the answer to a previous question I confused myself with (issue A model is invalid according to model.json but valid according to defs.json #1360) easier to implement for newcomers like me.
• It might also make it easier to keep schema-validation a requirement when using custom modifiers a la Application of POIs using formulas #850, feat: custom modifiers #1188, if the solution there uses user-defined schema extensions (somehow).

Code of Conduct

• I agree to follow the Code of Conduct