When an "official" FSL distribution is installed via the fslinstaller script, wrapper scripts for all FSL executables are created in $FSLDIR/share/fsl/bin/, so that all FSL executables can be added to the user $PATH without all executables in $FSLDIR/bin/ being added.
The new wrapper creation/removal scripts are located in the share/fsl/sbin/ directory - the intent is that the pre-unlink.sh and post-link.sh scripts of a FSL conda recipe will call these scripts during installation/removal of a FSL conda package.
Note that thhis MR includes a few rudimentary tests, and CI infrastructure for automatically running those tests (and integration with the fsl/fsl-ci-rules logic for automated conda builds).
Background
I think this is currently the best option out of the ones that have been discussed (in the related [non-existent, but perhaps should be for future code changes] gitlab issue). To make things clear, we need a solution which supports:
"Official" installation of a full FSL distribution (via the future fslinstaller)
Direct installation of a sub-set of FSL into a user-managed conda environment, via conda install
The problems we are trying to solve are solely related to official FSL installations:
Not clobbering the user $PATH with non-FSL commands that are installed into the same $FSLDIR/bin/, such as python, pip, conda, tcl, etc
Running FSL python commands in isolated mode, so that other Python libraries available in the user's environment do not clobber the Python libraries installed into $FSLDIR
Generating a "wrapper script" for every FSL command, and installing those wrapper scripts into an isolated directory allows these problems to be overcome:
The user can add $FSLDIR/fsl/share/bin/ to their $PATH instead of $FSLDIR/bin/
Wrapper scripts for Python commands can explicitly pass -I to the python interpreter so that it runs in isolated mode
Other proposals which were discussed and rejected:
Install everything directly into $FSLDIR/fsl/share/bin/
Would require all FSL scripts which refer to $FSLDIR/bin/, which would be a fair amount of work, but is possible, and hence not a show stopper
Would break third-party/user scripts which refer to $FSLDIR/bin/
would potentially have library linking issues, so would possibly need the Make system to be adjusted to be able to install into either $FSLDIR/bin/ or to $FSLDIR/fsl/share/bin/, which could get messy
Not "officially" possible for python projects (from what I could tell), so we would need to manually mv/cp python entry points from $FSLDIR/bin/ anyway, which feels just as hacky as a wrapper script
Sym-link rather than use wrapper scripts
Does not solve the python isolation problem, nor the problem of long hashbangs (although the latter could be considered a problem for the user)
