Extend Tool to allow execution of commands in path

In GitLab by @ererkka on Nov 13, 2020, 08:54

This is an example tool specification which describes my situation:

{
    "name": "AMIRIS",
    "description": "Run AMIRIS ABM simulation",
    "tooltype": "command",  <--- new type
    "command": "java",   <--- a command in path
    "cmdline_args": [   <--- arguments define more what’s going to happen
        "-cp", 
        "target\amiris-midgard-jar-with-dependencies.jar", 
        "de.dlr.fame.setup.FameRunner"
    ],
    "inputfiles": [],
    "inputfiles_opt": [],
    "outputfiles": [
        "result/FameResult.AMIRIS.pb"
    ],
}

Compared to Gimlet this process creates output files which I need to capture to next items. I know I could now put my java.exe to the executable field, but the solution is not portable at all.

In GitLab by @ererkka on Nov 13, 2020, 08:59

changed the description

In GitLab by @manuelma on Nov 13, 2020, 09:09

What about replacing the executable tool by this? It feels like strictly better in all ways.

Another thing that obviously comes to mind is support for defining output files in Gimlet (that get passed to next items).

In GitLab by @ererkka on Nov 13, 2020, 14:47

Either. I think Gimlet would still need the input/output file support, but then it’s very close to Tool...

In GitLab by @manuelma on Nov 13, 2020, 14:50

I think Gimlet already has input file support: You can check items in the available resource list and those files get copied to the work directory upon execution. But no way of passing output files at the moment, that's for sure.

In GitLab by @PekkaSavolainen on Nov 13, 2020, 15:10

Gimlet's do pass (relay) all file references and db url's to successor items. You can see what I mean if you do a DC->Gimlet->Importer or DS->Gimlet->Exporter, or even DC->Gimlet->Gimlet->Gimlet->Importer.

But it is true that there is no real output file support yet. I think adding that to Gimlet's would be a lot easier than modifying Tool and Tool specs to support what was suggested here.

In GitLab by @manuelma on Nov 13, 2020, 15:12

I don't think modifying the Executable tool specification is too difficult, is it?

In GitLab by @manuelma on Nov 13, 2020, 15:15

Actually, can somebody clarify why the executable tool spec doesn't work here?

In GitLab by @PekkaSavolainen on Nov 13, 2020, 15:20

I'd like to know that too, does it work if you set the full path to java.exe instead of using the one in PATH.

In GitLab by @PekkaSavolainen on Nov 13, 2020, 15:34

You may be right. ExecutableTool and ExecutableToolInstance are quite small actually. Maybe it is easier to enable calling programs in PATH via an Executable tool specification after all.

In GitLab by @manuelma on Nov 13, 2020, 15:37

And it would be even easier if we only had to do it once (by dropping the regular engine beforehand, spine-tools/spine-engine#14).

In GitLab by @ererkka on Nov 16, 2020, 11:45

It might work by setting the full path to e.g. java.exe. But java.exe certainly should not be copied to a working dir or anything like that.

In GitLab by @manuelma on Dec 4, 2020, 09:51

I think we should allow Tool to not have a script. In this case what gets executed would be simply the command line arguments, and the executable Tool could effectively replace Gimlet.

In GitLab by @PekkaSavolainen on Dec 22, 2020, 12:59

moved to spine-tools/Spine-Toolbox#937