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
This is a proposed alternative structure for #2741. I wanted to generate it and then lay it side by side against the current proposal there.
(Browsing the code on this branch might communicate such better than the PR)
Admittedly there's some stuff in here that I have done along the way that is not totally specific to this proposal; that is, even if the core of this proposal is rejected, some of the content here would still be applicable to whatever alternative were to be chosen.
So the main points here:
Both source files specific to an individual command, and the API modules, reside in python/mrtrix3.
They do not need to reside in something called lib/ in the source tree, since they shouldn't be getting included from there directly.
I do however keep a "mrtrix3" subdirectory since that will likely give IDEs a bit of assistance.
All commands are stored in a sub-directory of python/mrtrix3, regardless of whether or not they possess multiple underlying algorithms.
On #2741, some commands are standalone .py files, others contain their own subdirectories. This is a bit clumsy both when navigating, and in the cmake code, as it changes the content that needs to be written to the executable file.
The sub-directories for the various commands reside within python/mrtrix3, alongside the utility module files.
2741 currently has these grouped in a sub-directory "scripts/"; perhaps if an unnecessary subdirectory can be avoided it might be preferable.
Every command has had the code corresponding to the requisite usage() and execute() functions split between two separate files. Some commands also have additional code separated into their own files.
Having so many occurrences of "usage.py" and "execute.py" is quite strange, particularly when dealing with maintenance on the whole code base; but if just working on one command at a time, it probably doesn't matter.
If anything is going to result in this proposal getting rejected, this is probably it.
This would both facilitate breaking up some currently unwieldy large files, and encourage better Pythonic modularisation of future additions.
Some commands have separate files corresponding to tiny-to-empty functions for dealing with inputs and outputs. With #2678 that handling changes, such that those functions (and consequently files) will disappear.
(PS. I'm aware that merging this against #2678 will be a nightmare... but I'll deal with it)
This is a proposed alternative structure for #2741. I wanted to generate it and then lay it side by side against the current proposal there. (Browsing the code on this branch might communicate such better than the PR)
Admittedly there's some stuff in here that I have done along the way that is not totally specific to this proposal; that is, even if the core of this proposal is rejected, some of the content here would still be applicable to whatever alternative were to be chosen.
So the main points here:
Both source files specific to an individual command, and the API modules, reside in
python/mrtrix3.lib/in the source tree, since they shouldn't be getting included from there directly.mrtrix3" subdirectory since that will likely give IDEs a bit of assistance.All commands are stored in a sub-directory of
python/mrtrix3, regardless of whether or not they possess multiple underlying algorithms. On #2741, some commands are standalone.pyfiles, others contain their own subdirectories. This is a bit clumsy both when navigating, and in thecmakecode, as it changes the content that needs to be written to the executable file.The sub-directories for the various commands reside within
python/mrtrix3, alongside the utility module files.2741 currently has these grouped in a sub-directory "
scripts/"; perhaps if an unnecessary subdirectory can be avoided it might be preferable.Every command has had the code corresponding to the requisite
usage()andexecute()functions split between two separate files. Some commands also have additional code separated into their own files.usage.py" and "execute.py" is quite strange, particularly when dealing with maintenance on the whole code base; but if just working on one command at a time, it probably doesn't matter. If anything is going to result in this proposal getting rejected, this is probably it.(PS. I'm aware that merging this against #2678 will be a nightmare... but I'll deal with it)