Needed: Conditional parameter overrides depending on parameter spec

[adswa]

#359 introduced a recursion limit of 1 to get. I just ran a get on the toplevel dataset of ///, and it seemed to install all available subdatasets - I killed the process after 203 installed subdatasets. The what I would assume equivalent command datalad get -n . -r -R 1 installs 34 subdatasets.

The command summary confirms that the recursion limit isn't passed through:

Dataset('/tmp/bigone').get(get_data=False, recursive=True)

The problem is that any default not in the exposed parameters doesn't make it into the command argument list that gets executed - if I see it correctly, they are taken directly from the configuration widget where recursion_limit is not exposed.

[adswa]

I stumbled over #242 again, and I think that a general 'conditional constraint' mechanism could fix both of these issues. #242 complains that a drop --what datasets --reckless kill requires a --recursive flag (but as the error message and the parameter description for reckless in the simplified API suite differ, this is hard to infer for users). If we had means to specify "if exactly this parameter set is provided, also add this one" we could automatically add -R 1 whenever there is a get --recursive and add --recursive whenever there is drop --what datasets --reckless kill. Those "conditional_constraints" could be specified in the API suite as an additional section per command.

[adswa]

tagging @mih because we just chatted how such an approach could make sense in his current work on constraints. It needs to be a slightly different constraint mechanism to the one currently implemented that, if invalid, adds parameters automatically