Constraints demo

[adswa]

This is a small demonstration of using datalad-next constraints for metalad commands using meta-extract and meta-dump. Its a draft PR because it depends on changes from today that haven't even been merged, and there is still one remaining check/constraint to implement to ensure Datasets have a valid dataset ID (so one test will fail no matter what).

I see the following advantages:

• metalad drives development in datalad-next: Giving the constraints some real world exposure helps identify and fix shortcomings and can lead to new constraints.
• useful sanity checks for metalad commands that can replace custom existing ones, or add entirely new ones
• Steps towards more consistent reporting

[adswa]

Exploration of the test failures:

---

FAILED ../datalad_metalad/extractors/tests/test_base.py::test_plainest - TypeError: one of the hex, bytes, bytes_le, fields, or int arguments must be given

• fails because the test expects a check for an invalid dataset ID, and there isn't one yet

---

FAILED ../datalad_metalad/tests/test_extract.py::test_extra_parameter_recognition - ValueError: /home/appveyor/DLTMP/datalad_temp_tree_test_extra_parameter_recognition71uthq8_/k1 does not exist

and

FAILED ../datalad_metalad/tests/test_extract.py::test_extractor_parameter_handling - ValueError: /home/appveyor/DLTMP/datalad_temp_tree_test_extractor_parameter_handling4rnierxm/k0 does not exist

• the failures seem legit - the test attempts to extract from a path that doesn't exist in the tree. Probably worth adjusting the test.

[adswa]

Note to self: meta-add has its own validity checks, one is check_dataset_ids, which checks that the dataset ID provided in the metadata record matches the dataset ID the metadata is added to; and process_parameters, which validates the presence or absence of metadata keys. I wonder whether some of their function could be done by a parameter constraint. At the moment, all of these checks run whenever a given metadata item is processed.