`ml` not found in many neurodesktop terminals

[gllmflndn]

ml or module is not found in a neurodesktop terminal opened by several applications:

spm12-r7771:~$ ml
bash: /usr/share/lmod/lmod/libexec/ml_cmd: No such file or directory

spinalcordtoolbox-5.4:~$ ml
bash: /usr/share/lmod/lmod/libexec/ml_cmd: No such file or directory

Different error with mricron:

mricron-1.0.20190902:~$ ml
bash: ml: command not found

But it does work for nipype:

nipype-1.8.3:~$ ml
No modules loaded

[gllmflndn]

Ah sorry it might be a feature according to this:

Also notice that the terminal that opens only allows to run utilities from the one application chosen in the menu. To be able to run utilities from multiple applications in the same terminal (or in the same script), please open a separate terminal

[stebo85]

Dear @gllmflndn - thank you for opening this issue :)

Yes, you are correct, this is actually a feature. The idea is that if users open a tool through the application menu they only get this tool and nothing else.

In nipype I enabled to load other tools as well.

What do you think, would it be easier for users if they can combine tools like what you tried from any container? Or should we keep the separation and add a more descriptive error message?

[gllmflndn]

With the principle of least surprise, I thought there would be no difference between opening a terminal and typing ml ants/2.3.5, and clicking on ants 2.3.5 in the desktop menu, or if there were, it would be that the latter would also display the content of the README.md file in the terminal. Is there a technical reason to prevent other tools to be loaded? Currently, with the error message, it feels that the system is broken. It also feels odd that the command that is executed from the menu, e.g. /neurocommand/local/bin/ants-2_3_5.sh works in a new terminal but not from the terminal opened by said menu.

Perhaps none of this matters but I came across it when trying to execute the nipype example that is displayed from the spm12 r7771 README.md: pip cannot be found and trying to install ml nipype/1.8.3 fails too. As you point out, this will work from a new terminal or from a nipype terminal.

[stebo85]

yes, good points - I see what I can do to make these two things behave identically. Currently opening a tool via the menu gives you a "foolproof" way to just use the tool. Using the tools via ml from a normal terminal is a more advanced usecase.

But I totally agree, that it would be easier if there was only one workflow and the behaviour identical. I think it's possible.

[stebo85]

@aswinnarayanan - my initial idea is to use the same mechanism in the menu system (ml) instead of singularity shell - this would make the behaviour identical.

It comes with the downside that if a user tries to debug the container (e.g. running the python inside the container will now call the desktop python) we need to write a piece of documentation that shows how to access the isolated container? Any other things you foresee? Should we add this feature to neurocommand and control it via an environment variable so we are not breaking existing peoples workflows, but new updates will make it the default?

[aswinnarayanan]

Sounds like a good idea. We should also override the bash prompt when a module is loaded via the menu to let the user know the application is loaded.

e.g. running the python inside the container will now call the desktop python

I'm trying to think where this could be an issue. This is only giving access to host applications that previously weren't accessible correct? I can't think of any downsides.

We can also control/override this behaviour using the neurocommand config