Details
-
Type:
Task
-
Status: Open
-
Priority:
Blocker
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: 1.7.3
-
Component/s: Automation and Event Handling
-
Sprint:1.7 Sprint 4, 1.7 Sprint 5, 1.7 Sprint 6, 1.7 Sprint 7, 1.7 Release Sprint
-
Rank:0|0hzzkh:zzx
-
Sprint:1.7 Sprint 4, 1.7 Sprint 5, 1.7 Sprint 6, 1.7 Sprint 7, 1.7 Release Sprint
Description
Currently there's a one-to-one mapping between a scripting language and a script runner. The container-hosted and process-forked script runners may support multiple languages, since the execution context provides the actual language and dialect but launching a script in the execution context is the same action regardless of that. In fact, the idea of a "language" should be expanded to execution context or something like that. Execution context can be thought of as similar to a Python virtualenv, where the language version, installed packages, etc., varies but how the script is launched remains the same.
The remote execution context feature requires changes to this functionality:
- Launching process-forked executions is one script runner, while launching container-hosted executions is another
- The "supported languages" will actually be predicated on the known support for each environment. Currently there's a one-to-one relationship between a script language as displayed in the script editor and the supporting script runner. This needs to change so that a script runner can support multiple languages: the container-hosted runner may support pyxnat, bash, R, matlab, bash with FSL, Slicer, etc.
- Additionally script execution contexts should specify access and security levels to restrict access to dangerous or critical environments.