MRtrix3 provides a set of tools to perform various advanced diffusion MRI analyses, including constrained spherical deconvolution (CSD), probabilistic tractography, track-density imaging, and apparent fibre density
C++ commands must be defined using a single file cmd/cmdname.cpp
For Python commands there are three possible arrangements:
A single file python/mrtrix3/commands/cmdname.py.
A file python/mrtrix3/commands/cmdname/cmdname.py, to facilitate inclusion of other files within a sub-directory specific to that command.
Two files python/mrtrix3/commands/cmdname/usage.py and python/mrtrix3/commands/cmdname/execute.py, which define the relevant entry points.
It is being proposed in #2964 that:
For C++ it should be possible to have either:
A single file cmd/cmdname.cpp.
A file cmd/cmdname/cmdname.cpp, to facilitate inclusion of other files within a sub-directory specific to that command.
My proposal here is: especially if #2964 is implemented, providing support for 2.i.b., then it makes sense to remove support for 1.ii.c..
That way the supported filesystem structure per command will be consistent between the two languages. As shown by the content of this PR, there is little to no sacrifice in doing so; conversely there's the benefit of any communication around permissible filesystem structures likely being simpler.
Downstream of #2920.
Follows discussion in #2964.
Currently on
dev
:cmd/cmdname.cpp
python/mrtrix3/commands/cmdname.py
.python/mrtrix3/commands/cmdname/cmdname.py
, to facilitate inclusion of other files within a sub-directory specific to that command.python/mrtrix3/commands/cmdname/usage.py
andpython/mrtrix3/commands/cmdname/execute.py
, which define the relevant entry points.It is being proposed in #2964 that:
cmd/cmdname.cpp
.cmd/cmdname/cmdname.cpp
, to facilitate inclusion of other files within a sub-directory specific to that command.My proposal here is: especially if #2964 is implemented, providing support for 2.i.b., then it makes sense to remove support for 1.ii.c..
That way the supported filesystem structure per command will be consistent between the two languages. As shown by the content of this PR, there is little to no sacrifice in doing so; conversely there's the benefit of any communication around permissible filesystem structures likely being simpler.