Repository navigation
Slicer extensions may depend on Slicer, but not lie in the Slicer directory #1
Description
Activity
- added a commit that references this issue
on Jan 26, 2016 Interesting issue. It sounds like maybe something other than the path should be used to indicate the CLI entry points. It has always been a bit of an issue that slicer runs all executables in a directory somewhat blindly and with full user permissions, so making the process more explicit could be good. Perhaps an explicit entry point like CLI.sh (CLI.bat?) should be required and that would include the launcher command which is really proper to the CLI and not something the framework should really consider.
Thank you very much for your thoughts. Actually, I did not even think about permissions etc., I guess that would open yet another can of worms. I also believe that part of the beauty of CLI modules is their simplicity. Of course, things like Docker images would be a logical next step, but CLIs are useful due to their simplicity (and size, and efficiency, to some degree).
You are right, that the launcher command and environment are properties of the CLI module; this is a central observation. CLIs are self-descriptive only as long as they are callable. So we are in the unfortunate situation that most of the "metadata" of a CLI is available via
--xml, but we need a tiny bit extra, namely how to be able to get to that.On the other hand, I also need to find a solution that works now, so I cannot wait until all extensions come with additional wrapper scripts. (An interesting idea, but that would probably require a convention on a common basename in order for the additional .exe to be ignored, or would you move it into a separate directory, then?)
I agree we should go for simplicity at the interface side and encapsulate
any cli-specific complexities to the cli provider, possibly as part of
their packaging process.For slicer3 we had a problem on mac where CLIs were slow to start up and
would eventually time out (due to all the shared library dependencies for
ITK etc). So I wrote the script linked below that could be run once to
build a proxy script for each CLI that would return the --xml information
instantly or invoke the real CLI for other arguments. I could imagine
something similar that generates a launcher wrapper script (and maybe also
does the --xml trick for efficiency).https://github.com/pieper/Slicer3/blob/master/Scripts/cli-proxies.tcl
On Tue, Jan 26, 2016 at 10:13 AM, Hans Meine notifications@github.com
wrote:Thank you very much for your thoughts. Actually, I did not even think
about permissions etc., I guess that would open yet another can of worms. I
also believe that part of the beauty of CLI modules is their simplicity. Of
course, things like Docker images would be a logical next step, but CLIs
are useful due to their simplicity (and size, and efficiency, to some
degree).You are right, that the launcher command and environment are properties of
the CLI module; this is a central observation. CLIs are self-descriptive
only as long as they are callable. So we are in the unfortunate situation
that most of the "metadata" of a CLI is available via --xml, but we need
a tiny bit extra, namely how to be able to get to that.On the other hand, I also need to find a solution that works now, so I
cannot wait until all extensions come with additional wrapper scripts. (An
interesting idea, but that would probably require a convention on a common
basename in order for the additional .exe to be ignored, or would you move
it into a separate directory, then?)—
Reply to this email directly or view it on GitHub
#1 (comment).
On Windows, I am trying to detect the presence of Slicer.exe relative to the CLI executable, in order to use it as wrapper (i.e.,
Slicer.exe --launch --launcher-no-splash path_to_real_cli.exe ...). However, Slicer may nowadays also put extensions under paths like%AppData%\Roaming\NA-MIC\Extensions-24735. This way, my code for detecting relative paths toSlicer.exefails, and e.g. the ChestImagingPlatform CLIs do not run because of missing ITK DLLs.I see two main options:
%AppData%\Roaming\NA-MIC\Extensions-[0-9]*to be a Slicer-path, and locating any installed Slicer in a default location on that machine. I don't know how reliable that would be, e.g. whether I can useos.environ["ProgramFiles"]to locate Slicer).In both cases, it would be hard to guarantee that the correct Slicer version is found and used for all CLIs.