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).
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:
fslinstaller
)conda install
The problems we are trying to solve are solely related to official FSL installations:
$PATH
with non-FSL commands that are installed into the same $FSLDIR/bin/
, such as python
, pip
, conda
, tcl
, etc$FSLDIR
Generating a "wrapper script" for every FSL command, and installing those wrapper scripts into an isolated directory allows these problems to be overcome:
$FSLDIR/fsl/share/bin/
to their $PATH
instead of $FSLDIR/bin/
-I
to the python interpreter so that it runs in isolated mode
Other proposals which were discussed and rejected:
$FSLDIR/fsl/share/bin/
$FSLDIR/bin/
, which would be a fair amount of work, but is possible, and hence not a show stopper$FSLDIR/bin/
$FSLDIR/bin/
or to $FSLDIR/fsl/share/bin/
, which could get messymv
/cp
python entry points from $FSLDIR/bin/
anyway, which feels just as hacky as a wrapper script