Context
PR #16 added frictionless>=5,<6 to requirements-dev.txt so the pytest
suite can validate datapackage.json against the Frictionless Data
Package spec. The validation itself is one assertion: zero errors from
Package.metadata_validate(...).
Problem
frictionless is a heavyweight library. It pulls in roughly a dozen
transitive deps (chardet, attrs, marko, jinja2, stringcase, simpleeval,
and a CLI surface) for a repo whose stated identity is "small,
agent-friendly metadata". One assertion in one test is paying for the
whole footprint, including pieces (tabular validation, datasette
integration, etc.) we don't use.
A possible alternative
Bundle the Frictionless Data-Package JSON Schema as a static file under
schemas/vendored/ and validate against it with the jsonschema lib
that's already in requirements-dev.txt. Same coverage, no new
transitive deps. The trade-off is that we'd be pinning to whatever
version of the profile we vendor, and we'd refresh it manually when
Frictionless ships a new one — versus today's "the version we depend on
defines the spec we're checking against".
Not picking a side
The pytest assertion in PR #16 is genuinely useful and runs fast enough.
This issue is just to mark the question — "do we want to carry the dep
weight, or vendor the schema?" — so it doesn't get lost. Either outcome
is defensible.
Context
PR #16 added
frictionless>=5,<6torequirements-dev.txtso the pytestsuite can validate
datapackage.jsonagainst the Frictionless DataPackage spec. The validation itself is one assertion: zero errors from
Package.metadata_validate(...).Problem
frictionlessis a heavyweight library. It pulls in roughly a dozentransitive deps (chardet, attrs, marko, jinja2, stringcase, simpleeval,
and a CLI surface) for a repo whose stated identity is "small,
agent-friendly metadata". One assertion in one test is paying for the
whole footprint, including pieces (tabular validation, datasette
integration, etc.) we don't use.
A possible alternative
Bundle the Frictionless Data-Package JSON Schema as a static file under
schemas/vendored/and validate against it with thejsonschemalibthat's already in
requirements-dev.txt. Same coverage, no newtransitive deps. The trade-off is that we'd be pinning to whatever
version of the profile we vendor, and we'd refresh it manually when
Frictionless ships a new one — versus today's "the version we depend on
defines the spec we're checking against".
Not picking a side
The pytest assertion in PR #16 is genuinely useful and runs fast enough.
This issue is just to mark the question — "do we want to carry the dep
weight, or vendor the schema?" — so it doesn't get lost. Either outcome
is defensible.