Restore templates to docker image

[effigies]

With the templates removed from docker #157, testing fixes with a reused working directory takes a long time, since the templates have to be redownloaded every time.

@oesteban Has recent work in templateflow changed the balance pros and cons discussed in #157 (comment)?

[oesteban]

Sorry, I've been meaning to reply to this for a long while.

testing fixes with a reused working directory takes a long time, since the templates have to be redownloaded every time.

This should not be the case. I'm afraid what could be happening is that the automatic templateflow update comes with overwrite=True, and therefore the templateflow home is wiped out always. In other words, even re-including the templates in the docker image this problem will persist.

The short-term solution is running the docker container setting -e TEMPLATEFLOW_AUTOUPDATE=off. The long term solution is templateflow/python-client#52.

If that doesn't work (it should), I'd be fine with putting some templates back in the image (we'll need to check the bug does not regress in doing so). But we may want to take the opportunity to refactor how we build all our images with multi-staged builds. We could generate a lightweight docker image for templateflow (kept updated with the python-client repo actions) with a minimal amount of templates pre-fetched. Multi-staged builds might save us a lot of time when the cache goes stale and we need to install freesurfer, FSL, or the base conda environment.

I don't know how singularity build docker:// will handle multi-stage builds, though.

[oesteban]

Hey @mgxd, could you check on the multi-staged builds and give us a blitz in the next IT meeting?

[oesteban]

After the PR referenced above, I think the concerns raised in this issue have been addressed, and currently CircleCI is reusing TemplateFlow cached objects while respecting Nipype's cache. I'll close this for the time being, but feel free to reopen if you think this still needs to be considered.