-
Notifications
You must be signed in to change notification settings - Fork 298
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FIX: Properly mount local templates #2020
Conversation
Thank your for raising your pull request. Some of the fMRIPRep maintainers will review your changes as soon as time permits. PR ReviewPlease check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide
Please check what applies in the following aspects of the PR: Code documentation
Documentation site
Tests
Data
Dependencies: smriprep
Dependencies: niworkflows
Dependencies: sdcflows
Dependencies: Nipype
Dependencies: other
Reports generated within CI tests
|
command.extend(['-v', ':'.join((os.path.abspath(space), target, 'ro'))]) | ||
spaces.append(target) | ||
spaces.append(tpl[4:]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like we're baking in some assumptions that the directory will be called tpl-XYZ
. We should either require that (error if tpl[:4] != 'tpl-'
) or be a bit more forgiving (if not tpl.startswith('tpl-'): tpl = 'tpl-' + tpl
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, we can add a check to ensure the directory is compliant with templateflow standards.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may be obvious, but in case you're about to do a significant amount of work, I would really keep this very simple. If the error is going to show up early and be clear inside fMRIPrep proper, then we really don't need to do anything here.
I'm mostly worried about if somebody types --output-spaces /my/template
and gets strange errors about "tpl-late not found", or something like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since this check is happening within the niworkflows SpatialReference, that would probably be the best place for that. Since the wrapper behavior is a little different (it has to actually mount the directory), we can include a check here too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Merge notes: * Fix gh-2014 appears to have been made unnecessary by gh-2018. Tag message: 20.0.2 (March 6, 2020) ====================== A bug squashing release in the 20.0.x series. This release fixes the use of custom templates within the docker wrapper, remedies crashes when FreeSurfer HOME was not set, and improves the documentation for local installations. With thanks to Blaise Frederick for the contribution. * DOC: Update standalone installation requirements (#2009) * FIX: Crashes whenever FREESURFER_HOME is not set (#2014) * FIX: Local template mounting (wrapper) (#2020) * MAINT: Pin minor series of nipype, major series of nibabel (#2021)
This PR re-enables use of custom templates after the output spaces refactoring.
The local directory where the custom template exists is now mounted to the TemplateFlow home within the container.
Related issue: https://neurostars.org/t/custom-template-fmriprep-20-0-1/6232