Better handling of new tool configs for BoutiquesTask #1584
Description
When an admin configures a new ToolConfig, they can provide an arbitrary version name.
These work fine for standard tool integration (the ones where a programmer has to create Ruby code for the portal and bourreau under a class that starts with CbrainTask:: ).
It doesn't work well for tools integrated automatically with the new Boutiques integrator (those where the task class starts with BoutiquesTask:: ) . The reason is that the version_name attribute is used to look up which boutiques descriptor to associate with the config. If the admin provides a version_name that is not found in any descriptors, the interface will not work.
So the interface should validate the version name if possible.
That leads us to a potential new feature:
The only way right now to install new variants of the exact same tool integration that has a different name is to install a full copy of the JSON descriptor, WITH the name change in it.
It would be great if tool configs had a new attribute, "base_descriptor_tool_version", which if filled would be used to make the look up. That way an admin could configure a new 'virtual' version of an existing tool.
Say there exists a tool SuperTool with version "1.0" properly installed with a descriptor (meaning the descriptor contains in its JSON the property "tool-version": "1.0"). The admin wants to create a new tool config for SuperTool with some special properties (e.g. cuda queue), while keeping everything else identical to 1.0. So the admin would enter in the form:
Tool: SuperTool
VersionName: 1.0-Cuda # standard attribute tool_version, which is what users see
BaseDescriptor: 1.0 # new attribute base_descriptor_tool_version, which will be use by the integrator