Closed jsheunis closed 1 year ago
@mslw I think this comment from above is particularly relevant to you, since you also maintain a couple of translators:
Translation functionality is refactored, and requires updated to existing translators:
- With the new catalog argument, translation occurs to the specific schema version of the catalog (if supported by an available translator); if the catalog argument is not supplied, the expected schema version is the latest supported by the package installation.
- The translator matching process is streamlined by keeping track of previously matched and instantiated translators
- Functionality to get the supported schema version, source name, and source version have been moved to the translator base class in order to support the abovementioned changes. This means existing and new translators will have to override these functions.
Patch coverage: 91.45
% and project coverage change: +3.81
:tada:
Comparison is base (
f612cb1
) 82.32% compared to head (57bf6b4
) 86.14%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
The main goal of this PR is to close https://github.com/datalad/datalad-catalog/issues/245. IN the process, the PR evolved a lot and now includes these main changes:
datalad-next
dependency, at first for constraint system but in future for whatever functionality is usefulSome specific outcomes to take note of:
path-to-catalog/schema/*
), where previously validation was always done according to the latest schema of the installed package version (which is now the fallback).tests/fixtures.py
and exposed to all testscatalog-get|set
provides an extensible set of commands for configuring a catalog and reporting its propertiesIssues that are addressed by this PR:
101
128
148
179
183
195
245
254
259
264
265
305
316
318
324