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
and the 2nd one (repronim-reproin-dev) provides demonstration on how to reuse the same container but with an overloaded reproin command e.g. during active development of a new feature -- so there is no need to create a new container just to try a new version of the reproin script -- code/reproin is also just a git submodule pointing to this repo.
Then in such a dataset, upon getting some data to convert I just need to run
(note the "cons" of needing to specify the study although it should be known since we are in that location... RFing of the interface should take that into account).
Here is a bash dump of commands for a recent similar setup with an "outdated" reproin since that is what study used already. It also includes TODO comments . Relevant issue on datalad side: datalad/datalad#5950 on how to configure ephemeral clone (I should have cloned locally ephemeral and then adjusted URL in .gitmodules):
cd /inbox/BIDS/Wager/Wager/1090_tdcs/
# TODO: should have instead done ephemeral clone to not later carry a copy of images
datalad install -d . --source ///repronim/containers code/containers
cd code/containers
git remote add --fetch local ~/repronim-containers
# check which dcm2niix was used, we only recently started to add heudiconv version in
git grep Software
grep v1.0.20211006 ~/reproin-dcm2niix-versions.tsv
# unfortunately freeze_version does not work when we are not under that dataset. TODO
cd code/containers/
scripts/freeze_versions --save-dataset=$PWD/../.. repronim-reproin=0.11.3
datalad get images/repronim/*0.11.3*
cd -
# freeze_versions didn't save actually !
datalad save -d^ -m "Added definition of containers.repronim-reproin frozen to 0.11.3. updateurl is wrong" .datalad/config
the problem comes that it is only recently that we started to copy reproin script inside the container:
so we do not have it inside... (yet to decide if that was a good decision anyways). So we will follow the setup above to include another submodule and bind mount reproin inside and use it. We also adding bind mounts -B /inbox/DICOM/ -B /inbox/BIDS (a little of non-YODA in that ...)...
this setup is also suboptimal since we are sandwiching datalad (and git-annex) outside and inside the container. It has shown to be fragile a number of times! So most likely reproin script should be made to be the "driver" outside, so installed "environment wide" and then it should use containers-run thus getting per conversion "datalad run" prov record.
The text was updated successfully, but these errors were encountered:
yarikoptic
changed the title
Document "ultimate" YODA setup
Document/establish "ultimate" YODA setup
Oct 17, 2023
Similarly to https://github.com/ReproNim/containers/#a-typical-workflow but for reproin. An example dataset which uses such setup is http://datasets.datalad.org/?dir=/dbic/QA (AKA
///dbic/QA
) where you can see https://datasets.datalad.org/dbic/QA/.datalad/config containingwhere both point to the subdataset
.code/containers
which is listed in https://datasets.datalad.org/dbic/QA/.gitmodules asand the 2nd one (repronim-reproin-dev) provides demonstration on how to reuse the same container but with an overloaded
reproin
command e.g. during active development of a new feature -- so there is no need to create a new container just to try a new version of the reproin script --code/reproin
is also just a git submodule pointing to this repo.Then in such a dataset, upon getting some data to convert I just need to run
(note the "cons" of needing to specify the study although it should be known since we are in that location... RFing of the interface should take that into account).
Here is a bash dump of commands for a recent similar setup with an "outdated" reproin since that is what study used already. It also includes TODO comments . Relevant issue on datalad side: datalad/datalad#5950 on how to configure ephemeral clone (I should have cloned locally ephemeral and then adjusted URL in .gitmodules):
the problem comes that it is only recently that we started to copy reproin script inside the container:
so we do not have it inside... (yet to decide if that was a good decision anyways). So we will follow the setup above to include another submodule and bind mount reproin inside and use it. We also adding bind mounts
-B /inbox/DICOM/ -B /inbox/BIDS
(a little of non-YODA in that ...)...this setup is also suboptimal since we are sandwiching datalad (and git-annex) outside and inside the container. It has shown to be fragile a number of times! So most likely
reproin
script should be made to be the "driver" outside, so installed "environment wide" and then it should usecontainers-run
thus getting per conversion "datalad run" prov record.The text was updated successfully, but these errors were encountered: