[feature] proto exec as option for moon tasks

[harlequin]

Describe the solution you'd like

It would be nice to have an attribute within options for setting proto exec as a kind of wrapper for the following command.

I would clearly state that this is only valid for commands and not scripts.

The huge benefit would be that we are developing and deploying a lot of tools via proto and using the activate_environment for specifying environment variables like JAVA_HOME.

When we want to to execute java -jar we have to have a .prototools within the execution directory in order to get the correct java version.

When now in the same execution directory another java tool will be called which is depending on another version of java, the .prototools will not support this natively.

So at the moment we are saying: proto exec java@21 -- java -jar this.jar and proto exec java@8 -- java -jar another.jar

So the options can look like this

options:
  proto_exec_args: ["java@21" ] // This shall be an array to support multiple tools

moon will than wrap the command into the proto exec $proto_exec_args --

So that we as endusers only declare:

java -jar this.jar in the command block

The proto_exec_args can also be extended to have the --tools-from-config to support the .prototools behaivour.

[milesj]

So moon doesn't actually use proto to run tasks, it just runs the binaries directly and relies on PATH modification for things to be available. There's no proto run usage, and will be no proto exec either.

I can look into calling the activate_environment though.

On a side note, is your java plugin built via WASM? Open to contributing it to core?

[harlequin]

@milesj: The usage of activate_environment sounds perfectly. But this would incline that the task builder has to read the .prototools in order to find the wasm plugins for the selected tool.

Important would be that the user can selected the plugins which shall be activated, like

[java@21, npm@latest, python]

only as example

In regards for your java question: Yes it's built via WASM but we are using an in house artifact storage and reading the released java versions for our company via this.
Means this public can't be used outside our environment.