search

datalad / datalad-ria

Adds functionality for RIA stores to DataLad
http://datalad.org
Other
0 stars 1 forks source link

ENH: Add to code fetching/"handling" of ria-layout-version #12

Open yarikoptic opened 4 years ago

yarikoptic commented 4 years ago

Came up in the review of datalad/datalad#4459, citing @mih:

re @yarikoptic You are correct that there is no trace of versioning in the code, because we are still at version 1, but the stores are versioned: http://store.datalad.org/ria-layout-version

It might become very valuable, especially for UX, if code (now) provisions what version(s) of the layout it currently supports (i.e., 1 ATM), and then announces if it detects layout version it does not support. We do already something similar in case installed datalad detects metadata which that version does not support (yet) and instructs user to upgrade: https://github.com/datalad/datalad/blob/c077fac5600c5aeeac65c529f914e3baa0d8ae02/datalad/metadata/metadata.py#L814

Ref also datalad/datalad#4410

bpoldrack commented 3 years ago

TODO here seems only to include supported versions in annex info ORA-REMOTE. If there's an unknown version we have a message announcing this. Wording of that message needs to be better, but it's there and (by default) the special remote would still try to read but refuse to write. This is because a different version may still have the relevant keys for an operation at the same location as the default version of the special remote - so we can try. But we don't want to write to possibly wrong locations w/o requiring the user to explicitly say "I know what I'm doing".

bpoldrack commented 3 years ago

@yarikoptic : Looking into this again, is there anything other than https://github.com/datalad/datalad/blob/66fd8be2cadeda3b85665ae63d407e2241e0bb1a/datalad/customremotes/ria_utils.py#L59 that is needed from your point of view?