Skip to content
VERASPEC
Repository
The conformance validatorstable

Schema resolution

A schema is looked for in three places, and the first hit wins:

  1. $VER_STANDARDS_ROOT when set;
  2. a standards tree found by walking up from the installed package, then from the working directory — under each candidate root the loader accepts standards/ver/<version>/, ver/<version>/ or <version>/;
  3. a copy shipped inside the wheel, at ver_validator/schemas/<version>/.
bash
VER_STANDARDS_ROOT=/srv/ver-standards ver-validate record.json --schema 1.0.1

Set VER_STANDARDS_ROOT to the directory containing standards/ver/.

The order reconciles two requirements that pull against each other. Reading the published artifact is the strong position: a validator carrying its own private copy of a schema can drift from the standard silently and then disagree with every other implementation about what is conformant. But a wheel carrying no schema is not a program — installed anywhere except a checkout of this repository it raised SchemaNotFoundError and validated nothing, which is a validator that works only where its answer is least needed. So the packaged copy is a fallback, never a first choice, and the drift it risks is prevented mechanically instead of by omission: the copies are byte-identical to standards/ver/<version>/ver-record.schema.json, and tests/test_profile_validator.py::test_the_packaged_schema_copy_is_byte_identical_to_the_published_one compares the bytes, so a divergence fails CI rather than shipping. Re-copy verbatim after any schema change:

bash
cp standards/ver/1.0.1/ver-record.schema.json \
packages/ver-validator/src/ver_validator/schemas/1.0.1/ver-record.schema.json
cp standards/ver/1.1-draft/ver-record.schema.json \
packages/ver-validator/src/ver_validator/schemas/1.1-draft/ver-record.schema.json

The draft copy is held to the same byte-identity rule as the published ones (tests/test_record_1_1_profile.py::test_the_packaged_1_1_draft_copy_is_byte_identical_to_the_published_one), and test_the_packaged_copies_cover_exactly_the_supported_releases requires a packaged copy for every entry of SCHEMA_VERSIONS — a release the validator offers but cannot load from an installed wheel is not supported.

schema_path(version) still reports only where the published artifact is on disk and raises SchemaNotFoundError when no tree carries it — answering it with a path inside site-packages would misreport a validator running on its own copy as one running on the standard. load_schema(version) is the function that falls back. An unknown version is a ValueError from all three loaders, so the fallback is not a laxer door into version selection.