You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think, indeed, we should re-approach validation of the dandiset.yaml here.
we should add validation to --upload-dandiset-metadata option block with the same behavior as we have for assets in terms of --validation option.
generally local dandiset.yaml might differ from the metadata record on the server.
validating local one makes little sense unless it being uploaded (see above -- we will validate in that case)
if we are not uploading it, we should validate/inform user about state of the remote/on the server dandiset.yaml (also subject to --validation option)
I do not think we should preclude upload overall if dandiset metadata record is failing validation, as we do not preclude upload of an asset if some other asset is faulty.
the key question is whether you expect to only get dandiset id from dandiset.yaml, or do you expect anything more than that. if the former, then it doesn't matter if the rest is valid or invalid.
however, i think the CLI is always an opportunity to inform the user to fix/update something. think npm serve as an analog. it always tells you which packages have critical issues, and also provides an autofix for some of the issues. thus the cli could start helping the user to automate more tasks (using LLMs or other similar tools as well).
prompted by @satra's question in
ATM:
--upload-dandiset-metadata
but we are not validating.I think, indeed, we should re-approach validation of the dandiset.yaml here.
--upload-dandiset-metadata
option block with the same behavior as we have for assets in terms of--validation
option.dandiset.yaml
might differ from the metadata record on the server.--validation
option)WDYT @satra @jwodder ?
The text was updated successfully, but these errors were encountered: