Do not silently start downloading missing bits assuming installation in hard-coded default locations

[sanjayankur31]

I have jnml installed in the right location: /usr/bin/. However, because OMV has the default location hard-coded as ~/jnml/jNeuroMLJar/, if it doesn't find it there, it just starts to download the thing. There's really no reason why users should have individual directories in ~/ for each software. This is not a standard location (not FHS or XDG or any other standard that I'm aware of). Most people will have a specific folder where they install software locally. So, this needs to be improved:

We should:

• first check a list of sane default locations: such as $PATH on Linux systems to see if the necessary command is available
• if the command is not found, we should inform the user and ask them to explicitly set the necessary environment variable to point to their installation,
• a specific value of the environment variable could be used to request OMV to download the artefact itself. For example JNML_HOME="omv-download".

[pgleeson]

Good point. I think to be honest it might be time to move away from installing the simulators by default, so if you run a test when that engine isn't installed:

omv test /test.jnml.omt   # will fail, with a suggestion to explicity run 'omv install jneuroml' & give a tip on setting the env path

omv test -install /test.jnml.omt
omv all -install                                # These will both try to install any engines it doesn't find 

Thoughts @borismarin?

[borismarin]

I have never been a fan of polluting ~/ either; there was an issue a long time ago which was also motivated by this behaviour. Yet another case of quick and dirty (this code started as quick way get a simulation environment running on CI machines - since they are intended to be throwaway images, we never bothered about interactive sessions) solutions that become permanent. Having seen that people indeed tend to use omv locally, that definitely needs to be addressed - maybe starting with eliminating omv "dependency management" altogether.

OTOH, Padraig and I had some discussions (ca. 2014) regarding "standardised" simulator installations that would contribute towards "reproducible" validation (IIRC we were struggling with numerical fluctuations in Genesis due to different library versions); I guess there are plenty of different ways to solve that, including providing binaries (which I was trying to do in the conda branch), package manager 'recipes' etc.

Everyone knows about Docker and Conda nowadays, so we might be in a better position to decide which option would make more sense.