Code changes to make this repo compatible with datalad-catalog>=1.1.0 #46
Conversation
|
The appveyor run fails because it still installs the older version of Same problem noted here: #42 (comment) |
There was a problem hiding this comment.
Bundling an updated catalog would have several advantages, incl. fixing the caching issues (datalad/datalad-catalog#457) recently reported by e-mail by @ste-phi
@jsheunis it's been a while but do you think it's good to go?
It builds a catalog for me when tested on some of my local data, so for me that's a yes.
| catalog_add( | ||
| catalog=catalog_path, | ||
| metadata=study_entry, | ||
| ) |
There was a problem hiding this comment.
Maybe - just maybe - this could have default tab set to subdatasets (the study dataset has only subdatasets, no content) but IIRC catalog_add can take only a config file, not an individual option, so I'm not inclined to change it here.
There was a problem hiding this comment.
but IIRC catalog_add can take only a config file, not an individual option
That's correct. There was an intention to update the code of catalog_set to allow the config option, which would reset the config. But this hasn't been implemented.
| @@ -3,5 +3,5 @@ datalad-next | |||
| pydicom | |||
| pytest | |||
| pytest-env | |||
| datalad-catalog==0.2.1b0 --pre | |||
| datalad-catalog | |||
There was a problem hiding this comment.
I wonder if it would make sense to still pin the version, just to the current one, to avoid having to deal with future changes? Or is that unnecessary?
| datalad-catalog | |
| datalad-catalog==1.1.1 |
There was a problem hiding this comment.
I think ideally we wouldn't pin it, but under the circumstances of datalad-catalog receiving breaking changes sometimes, and the future development being unclear at the moment, I would agree with pinning it here.
|
Looks good. I reran the PR appveyor job and all are successful now. |
Closes #43