==========================================
Slicer CLI Web |build-status| |codecov-io|
==========================================
A Girder plugin for exposing slicer execution model CLIs over the web using docker and girder_worker.
Installation
------------
Slicer CLI Web is both a Girder_ plugin and a `Girder Worker`_ plugin. It allows dockerized tasks to be run from the Girder user interface.
Linux
=====
In linux with Python 3.6, 3.7, 3.8, 3.9, or 3.10:
Prerequisites:
- An appropriate version of Python must be installed.
- MongoDB must be installed and running.
- RabbitMQ or another broker is needed to use Girder Worker.
- Docker must be installed and the current user must be part of the docker group.
To use Girder:
.. code-block:: bash
pip install girder-slicer-cli-web[girder]
girder build
girder serve
To use Girder Worker:
.. code-block:: bash
pip install girder-slicer-cli-web[worker]
GW_DIRECT_PATHS=true girder_worker -l info -Ofair --prefetch-multiplier=1
The first time you start Girder, you'll need to configure it with at least one user and one assetstore (see the Girder_ documentation). Additionally, it is recommended that you install some dockerized tasks, such as the HistomicsTK_ algorithms. This can be done going to the Admin Console, Plugins, Slicer CLI Web settings. Set a default task upload folder, then import the ``dsarchive/histomicstk:latest`` docker image.
Girder Plugin
-------------
Importing Docker Images
=======================
When installed in Girder, an admin user can go to the Admin Console -> Plugins -> Slicer CLI Web to add Docker images. Select a Docker image and an existing folder and then select Import Image. Slicer CLI Web will pull the Docker image if it is not available on the Girder machine.
For each docker image that is imported, a folder is created with the image tag. Within this folder, a subfolder is created with the image version. The subfolder will have one item per CLI that the Docker image reports. These items can be moved after they have been imported, just like standard Girder items.
Running CLIs
============
When you visit the item page of an imported CLI, an extra ``Configure Task`` section is shown. You can set all of the inputs for the CLI and indicate where output files should be stored. Selecting ``Run Task`` will have Girder Worker execute the CLI. See the Jobs panel for progress and error messages.
Docker CLIs
-----------
Slicer CLI Web executes programs from docker images. Any docker image can be used that complies with some basic responses from its ``ENTRYPOINT``.
Specifically, when a docker image is invoked like::
docker run <docker image tag> --list_cli
it needs to respond with with a JSON dictionary of CLIs, where the keys of this dictionary are the names of the CLIs. See `cli_list.json <./small-docker/cli_list.json>`_ for an example.
Each available CLI needs to report what it takes as inputs and outputs. When the docker image is invoked like::
docker run <docker image tag> <cli name> --xml
it needs to return an XML specification to stdout. See `Example1.xml <./small-docker/Example1/Example1.xml>`_ for an example.
The XML must conform to the `Slicer Execution Schema <https://www.slicer.org/w/index.php?title=Documentation/Nightly/Developers/SlicerExecutionModel>`_, with a few minor additions:
- Some types (``image``, ``file``, ``transform``, ``geometry``, ``table``, ``directory``, ``item``) can have a ``reference`` property. When ``image``, ``file``, ``item``, ``directory`` are used with Girder, if the ``reference`` property is ``_girder_id_``, then value will be passed as a Girder ID string rather than converted to a Girder resource.
- The ``region`` type can have a ``coordinateSystem`` property.
- The ``region`` type has an optional ``shapes`` property that is a comma-separated list of values that can include ``default``, ``rectangle``, ``polygon``, ``line``, ``polyline``, and ``point``, plus ``multi`` and one of ``submit`` (or ``sibmitoff``), ``submiton``, or ``autosubmit``.
In the official schema, region is a vector of six values of the form x,y,z,rx,ry,rz, defining a rectangle based on its center and radius in each of three dimensions. This is the ``default`` shape. The ``rectangle`` shape allows a vector of four values defining a rectangle of the form x,y,width,height, where x,y is the left and top of the rectangle in pixel coordinates. Many algorithms that accept this value accept -1,-1,-1,-1 as a default to specify the whole conceptual space. The ``polygon`` shape allows for a list of x,y values. Polygons must always have at least four points so that the vector of values cannot be confused with the default; repeat the first vertex at the end to specify a triangle. The ``line`` shape allows a two-vertex line. To disambiguate this from a rectangle, the values -2,-2 are added after the line. The ``polyline`` shape allows a multi vertex line, indicated again by a -2,-2 value after the line. A ``point`` is a single vertex.
``multi`` allow multiple shapes, indicated by separating coordinates of each shape by -1,-1. Note that neither -1,-1 nor -2,-2 are allowed as coordinates within a shape -- to use those, specify them with decimals (e.g., -1.0,-1.0).
The submit options will add suggestions on how the UI should handle changes. If present, the option to auto-run a job as soon as a valid shape is set should be present. ``autosubmit`` means this should always happen. ``submit`` or ``submitoff`` offers this as a setting but is default to not submit the job. ``submiton`` offers this as a setting and defaults to submitting the job.
- Some input types (``image``, ``file``, ``item``, ``directory``) can have ``defaultNameMatch``, ``defaultPathMatch``, and ``defaultRelativePath`` properties. The first two are regular expressions designed to give a UI a value to match to prepopulate default values from files or paths that match the regex. ``defaultNameMatch`` is intended to match the final path element, whereas ``defaultPathMatch`` is used on the entire path as a combined string. ``defaultRelativePath`` is used to find a value that has a path relative to some base. In the Girder UI, this might be from an item.
- Input types can have a ``datalist`` property. If this is present, when the CLI is first loaded or, possibly periodically after parameters have been changed, the CLI may be called with optional parameters. The CLI is expected to return a new-line separated list of values that can be used as recommended inputs. As an example, a ``string`` input might have a ``datalist`` of ``--enumerate-options``; the cli would be called with the existing parameters PLUS the extra parameter specified by ``datalist``. If the result is sensible, the input control would expose this list to the user. The ``datalist`` property is a json-encoded dictionary that overrides other parameters. This should override parameters that aren't needed to be resolved to produce the datalist (e.g., input and output files) as that will speed up the call. The CLI should respond to the modified call with a response that contains multiple ``<element>some text</element>`` values that will be the suggested data for the control.
- There are some special string parameters that, if unspecified or blank, are autopopulated. String parameters with the names of ``girderApiUrl`` and ``girderToken`` are populated with the appropriate url and token so that a running job could use girder_client to communicate with Girder.
- Internally, the ``ctk_cli`` module is used. This has two differences from the Slicer Execution Schema that are technically bugs.
- Enumerations have bare elements under the appropriate parent tag. That is, instead of a structure like ``<string-enumeration>...<enumeration><element>Value 1</element><element>Value 2</element>...</enumeration></string-enumeration>``, the ``<enumeration>`` tag is omitted: ``<string-enumeration>...<element>Value 1</element><element>Value 2</element>...</string-enumeration>``.
- Booleans specify a true or false value after the flag or long flag. The Slicer Execution Schema states that booleans should be false by default and the presence of the flag should make them true. The ``ctk_cli`` specifies that they take a single ``true`` or ``false`` parameter. This doesn't change the xml; it changes what is passed to the CLI. Instead of passing ``--longflag`` to set the flag to true, ``--longflag true`` must be passed.
Docker CLIs with GPU support
----------------------------
When girder_worker runs docker images, the containers are started with gpu support only if the docker image has a label saying it should use an nvidia driver (add ``LABEL com.nvidia.volumes.needed=nvidia_driver`` to the Dockerfile).
--list_cli response format
==========================
The response from a docker image invoked with the ``--list_cli`` option needs to be a JSON response returning a single object. The object must contain a key for each CLI. Each key has a value used to parse or handle the CLI.
Here is a commented example::
{
// the key is the name of the CLI
"Example1": {
// type is typically either "python" or "cxx". The default program
// either runs "python <CLI key>/<CLI key>.py" for python or
// "<CLI key>/<CLI key>" for cxx.
"type": "python"
},
"Example2": {
"type": "python",
// The desc-type defaults to xml but can be any of "xml", "json", or
// "yaml". To get the CLI command line options, the CLI is invoked via
// docker run <docker image tag> <cli name> --<desc-type>
"desc-type": "json"
},
"AnotherName": {
// The alias allows the CLI to be invoked as either the key or the
// alias. This runs Example2 when invoked as AnotherName.
"alias": "Example2",
"type": "python"
},
"Example3": {
"type": "python",
// docker-params is a dictionary of parameters passed to the docker API
// when the docker container is created and run. Not all possible tags
// are passed through. See the docker python module for options:
// https://docker-py.readthedocs.io/en/stable/containers.html
"docker-params": {
"ipc_mode": "host"
}
}
}
CLI Endpoints
=============
Each exposed CLI is added as an endpoint using the REST path of ``slicer_cli_web/<docker image tag and version>/<cli command>/run`` and also using the REST path of ``slicer_cli_web/<internal item id>/run``, where ``<docker image tag and version>`` is the combined tag and version with slashes, colons, and at signs replaced by underscores. All command line parameters can be passed as endpoint query parameters. Input items, folders, and files are specified by their Girder ID. Input images are specified by a Girder file ID. Output files are specified by name and with an associated parameter with the same name plus a ``_folder`` suffix with a Girder folder ID.
Small Example CLI Docker
========================
The small example CLI docker image can be built locally via ``docker build --force-rm -t girder/slicer_cli_web:small .``, or pulled from Docker Hub.
Batch Processing
----------------
All CLIs that take any single item, image, or files as inputs can be run on a set of such resources from a single directory. For non-batch processing, the
ID of the image, item, or file is passed to ``<param>``. For batch processing, the ID of a folder is passed to ``<param>_folder`` and a regular expression is passed to <param>. All items in that folder whose name matches the regex are processed. For images, only items that contain large_images are considered. For files, the first file in each considered item is used.
If two inputs have batch specifications, there must be a one-to-one correspondence between the each of the lists of items determined by the folder ID and regular expression. All of the lists are enumerated sorted by the lower case item name.
When running a batch job, a parent job initiates ordinary (non-batch) jobs. The parent job will only start another child job when the most recent child job is no longer waiting to start. This allows non-batch jobs or multiple batch jobs' children to naturally interleave. The parent job can be canceled which will stop it from scheduling any more child jobs.
Templated Inputs
----------------
Any CLI parameter that takes a value that isn't a Girder resource identifier can be specified with a Jinja2-style template string.
For instance, instead of typing an explicit output file name, one can specify something like ``{{title}}-{{reference_base}}-{{now}}{{extension}}``. If this were being run on a task called "Radial Blur" on an image called "SampleImage.tiff", where the output image referenced the image image and had a list of file extensions starting with ".png", this would end up being converted to the value ``Radial Blur-SampleImage-20210428-084321.png``.
The following template values are handled identically for all parameters:
- ``{{title}}``: the displayed CLI task title.
- ``{{task}}``: the internal task name (this usually doesn't have spaces in it)
- ``{{image}}``: the tag of the Docker image used for the task
- ``{{now}}``: the local time the job started in the form yyyymmdd-HHMMSS. You can use ``yyyy``, ``mm``, ``dd``, ``HH``, ``MM``, ``SS`` for the four digit year, and two digit month, day, 24-hour, minute, and second.
- ``{{parameter_<name of cli parameter>}}``: any parameter that isn't templated can be referenced by its name. For instance, in Example1 in the small-docker cli in this repo, ``{{parameter_stringChoice}}`` would get replaced by the value passed to the stringChoice parameter.
- ``{{parameter_<name of cli parameter>_base}}`` is the same as the previous item except that if the right-most part of the parameter looks like a file extension, it is removed. This can be used to get the base name of file parameters.
The following template parameters are only handled on the web client:
- ``{#control:<selector>#}``: If specified for the value of a parameter, use the value of the selected field from the DOM. For instance, ``{#control:.h-zoom-value#}`` could get the current image zoom level.
There are also template values specific to individual parameters:
- ``{{name}}``: the name of this parameter. This usually doesn't have any spaces in it.
- ``{{label}}``: the label of the is parameter. This is what is displayed in the user interface.
- ``{{description}}``: the description of the parameter.
- ``{{index}}``: the index, if any, of the parameter.
- ``{{default}}``: the default value, if any, of the parameter.
- ``{{extension}}``: the first entry in the ``fileExtension`` value of the parameter, if any.
- ``{{reference}}``: if the parameter has a reference to another parameter, this returns that parameter's value. It is equivalent to ``{{parameter_<reference>}}``.
- ``{{reference_base}}``: the reference value mentioned previously striped of the right-most file extension.
If the local (server) environment has any environment variables that begin with ``SLICER_CLI_WEB_``, these are accessible in the templates as ``{{env_(name)}}``. For instance, ``SLICER_CLI_WEB_DASK_SERVER`` would be accessible as ``{{env_DASK_SERVER}}``.
.. |build-status| image:: https://circleci.com/gh/girder/slicer_cli_web.svg?style=svg
:target: https://circleci.com/gh/girder/slicer_cli_web
:alt: Build Status
.. |codecov-io| image:: https://codecov.io/github/girder/slicer_cli_web/coverage.svg?branch=master
:target: https://codecov.io/github/girder/slicer_cli_web?branch=master
:alt: codecov.io
.. _Girder: http://girder.readthedocs.io/en/latest/
.. _Girder Worker: https://girder-worker.readthedocs.io/en/latest/
.. _HistomicsTK: https://github.com/DigitalSlideArchive/HistomicsTK
Raw data
{
"_id": null,
"home_page": "https://github.com/girder/slicer_cli_web",
"name": "girder-slicer-cli-web",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.8",
"maintainer_email": null,
"keywords": "girder-plugin, slicer_cli_web",
"author": "Kitware, Inc.",
"author_email": "kitware@kitware.com",
"download_url": "https://files.pythonhosted.org/packages/5c/47/42a56b0f22463a110c7c58b05dc0aea316b6350ca787a3bff27348c8e551/girder-slicer-cli-web-1.5.4.tar.gz",
"platform": null,
"description": "==========================================\nSlicer CLI Web |build-status| |codecov-io|\n==========================================\n\nA Girder plugin for exposing slicer execution model CLIs over the web using docker and girder_worker.\n\nInstallation\n------------\n\nSlicer CLI Web is both a Girder_ plugin and a `Girder Worker`_ plugin. It allows dockerized tasks to be run from the Girder user interface.\n\nLinux\n=====\n\nIn linux with Python 3.6, 3.7, 3.8, 3.9, or 3.10:\n\nPrerequisites:\n\n- An appropriate version of Python must be installed.\n- MongoDB must be installed and running.\n- RabbitMQ or another broker is needed to use Girder Worker.\n- Docker must be installed and the current user must be part of the docker group.\n\nTo use Girder:\n\n.. code-block:: bash\n\n pip install girder-slicer-cli-web[girder]\n girder build\n girder serve\n\nTo use Girder Worker:\n\n.. code-block:: bash\n\n pip install girder-slicer-cli-web[worker]\n GW_DIRECT_PATHS=true girder_worker -l info -Ofair --prefetch-multiplier=1\n\nThe first time you start Girder, you'll need to configure it with at least one user and one assetstore (see the Girder_ documentation). Additionally, it is recommended that you install some dockerized tasks, such as the HistomicsTK_ algorithms. This can be done going to the Admin Console, Plugins, Slicer CLI Web settings. Set a default task upload folder, then import the ``dsarchive/histomicstk:latest`` docker image.\n\nGirder Plugin\n-------------\n\nImporting Docker Images\n=======================\n\nWhen installed in Girder, an admin user can go to the Admin Console -> Plugins -> Slicer CLI Web to add Docker images. Select a Docker image and an existing folder and then select Import Image. Slicer CLI Web will pull the Docker image if it is not available on the Girder machine.\n\nFor each docker image that is imported, a folder is created with the image tag. Within this folder, a subfolder is created with the image version. The subfolder will have one item per CLI that the Docker image reports. These items can be moved after they have been imported, just like standard Girder items.\n\nRunning CLIs\n============\n\nWhen you visit the item page of an imported CLI, an extra ``Configure Task`` section is shown. You can set all of the inputs for the CLI and indicate where output files should be stored. Selecting ``Run Task`` will have Girder Worker execute the CLI. See the Jobs panel for progress and error messages.\n\nDocker CLIs\n-----------\n\nSlicer CLI Web executes programs from docker images. Any docker image can be used that complies with some basic responses from its ``ENTRYPOINT``.\n\nSpecifically, when a docker image is invoked like::\n\n docker run <docker image tag> --list_cli\n\nit needs to respond with with a JSON dictionary of CLIs, where the keys of this dictionary are the names of the CLIs. See `cli_list.json <./small-docker/cli_list.json>`_ for an example.\n\nEach available CLI needs to report what it takes as inputs and outputs. When the docker image is invoked like::\n\n docker run <docker image tag> <cli name> --xml\n\nit needs to return an XML specification to stdout. See `Example1.xml <./small-docker/Example1/Example1.xml>`_ for an example.\n\nThe XML must conform to the `Slicer Execution Schema <https://www.slicer.org/w/index.php?title=Documentation/Nightly/Developers/SlicerExecutionModel>`_, with a few minor additions:\n\n- Some types (``image``, ``file``, ``transform``, ``geometry``, ``table``, ``directory``, ``item``) can have a ``reference`` property. When ``image``, ``file``, ``item``, ``directory`` are used with Girder, if the ``reference`` property is ``_girder_id_``, then value will be passed as a Girder ID string rather than converted to a Girder resource.\n\n- The ``region`` type can have a ``coordinateSystem`` property.\n\n- The ``region`` type has an optional ``shapes`` property that is a comma-separated list of values that can include ``default``, ``rectangle``, ``polygon``, ``line``, ``polyline``, and ``point``, plus ``multi`` and one of ``submit`` (or ``sibmitoff``), ``submiton``, or ``autosubmit``.\n In the official schema, region is a vector of six values of the form x,y,z,rx,ry,rz, defining a rectangle based on its center and radius in each of three dimensions. This is the ``default`` shape. The ``rectangle`` shape allows a vector of four values defining a rectangle of the form x,y,width,height, where x,y is the left and top of the rectangle in pixel coordinates. Many algorithms that accept this value accept -1,-1,-1,-1 as a default to specify the whole conceptual space. The ``polygon`` shape allows for a list of x,y values. Polygons must always have at least four points so that the vector of values cannot be confused with the default; repeat the first vertex at the end to specify a triangle. The ``line`` shape allows a two-vertex line. To disambiguate this from a rectangle, the values -2,-2 are added after the line. The ``polyline`` shape allows a multi vertex line, indicated again by a -2,-2 value after the line. A ``point`` is a single vertex.\n ``multi`` allow multiple shapes, indicated by separating coordinates of each shape by -1,-1. Note that neither -1,-1 nor -2,-2 are allowed as coordinates within a shape -- to use those, specify them with decimals (e.g., -1.0,-1.0).\n The submit options will add suggestions on how the UI should handle changes. If present, the option to auto-run a job as soon as a valid shape is set should be present. ``autosubmit`` means this should always happen. ``submit`` or ``submitoff`` offers this as a setting but is default to not submit the job. ``submiton`` offers this as a setting and defaults to submitting the job.\n\n- Some input types (``image``, ``file``, ``item``, ``directory``) can have ``defaultNameMatch``, ``defaultPathMatch``, and ``defaultRelativePath`` properties. The first two are regular expressions designed to give a UI a value to match to prepopulate default values from files or paths that match the regex. ``defaultNameMatch`` is intended to match the final path element, whereas ``defaultPathMatch`` is used on the entire path as a combined string. ``defaultRelativePath`` is used to find a value that has a path relative to some base. In the Girder UI, this might be from an item.\n\n- Input types can have a ``datalist`` property. If this is present, when the CLI is first loaded or, possibly periodically after parameters have been changed, the CLI may be called with optional parameters. The CLI is expected to return a new-line separated list of values that can be used as recommended inputs. As an example, a ``string`` input might have a ``datalist`` of ``--enumerate-options``; the cli would be called with the existing parameters PLUS the extra parameter specified by ``datalist``. If the result is sensible, the input control would expose this list to the user. The ``datalist`` property is a json-encoded dictionary that overrides other parameters. This should override parameters that aren't needed to be resolved to produce the datalist (e.g., input and output files) as that will speed up the call. The CLI should respond to the modified call with a response that contains multiple ``<element>some text</element>`` values that will be the suggested data for the control.\n\n- There are some special string parameters that, if unspecified or blank, are autopopulated. String parameters with the names of ``girderApiUrl`` and ``girderToken`` are populated with the appropriate url and token so that a running job could use girder_client to communicate with Girder.\n\n- Internally, the ``ctk_cli`` module is used. This has two differences from the Slicer Execution Schema that are technically bugs.\n\n - Enumerations have bare elements under the appropriate parent tag. That is, instead of a structure like ``<string-enumeration>...<enumeration><element>Value 1</element><element>Value 2</element>...</enumeration></string-enumeration>``, the ``<enumeration>`` tag is omitted: ``<string-enumeration>...<element>Value 1</element><element>Value 2</element>...</string-enumeration>``.\n\n - Booleans specify a true or false value after the flag or long flag. The Slicer Execution Schema states that booleans should be false by default and the presence of the flag should make them true. The ``ctk_cli`` specifies that they take a single ``true`` or ``false`` parameter. This doesn't change the xml; it changes what is passed to the CLI. Instead of passing ``--longflag`` to set the flag to true, ``--longflag true`` must be passed.\n\nDocker CLIs with GPU support\n----------------------------\n\nWhen girder_worker runs docker images, the containers are started with gpu support only if the docker image has a label saying it should use an nvidia driver (add ``LABEL com.nvidia.volumes.needed=nvidia_driver`` to the Dockerfile).\n\n--list_cli response format\n==========================\n\nThe response from a docker image invoked with the ``--list_cli`` option needs to be a JSON response returning a single object. The object must contain a key for each CLI. Each key has a value used to parse or handle the CLI.\n\nHere is a commented example::\n\n {\n // the key is the name of the CLI\n \"Example1\": {\n // type is typically either \"python\" or \"cxx\". The default program\n // either runs \"python <CLI key>/<CLI key>.py\" for python or\n // \"<CLI key>/<CLI key>\" for cxx.\n \"type\": \"python\"\n },\n \"Example2\": {\n \"type\": \"python\",\n // The desc-type defaults to xml but can be any of \"xml\", \"json\", or\n // \"yaml\". To get the CLI command line options, the CLI is invoked via\n // docker run <docker image tag> <cli name> --<desc-type>\n \"desc-type\": \"json\"\n },\n \"AnotherName\": {\n // The alias allows the CLI to be invoked as either the key or the\n // alias. This runs Example2 when invoked as AnotherName.\n \"alias\": \"Example2\",\n \"type\": \"python\"\n },\n \"Example3\": {\n \"type\": \"python\",\n // docker-params is a dictionary of parameters passed to the docker API\n // when the docker container is created and run. Not all possible tags\n // are passed through. See the docker python module for options:\n // https://docker-py.readthedocs.io/en/stable/containers.html\n \"docker-params\": {\n \"ipc_mode\": \"host\"\n }\n }\n }\n\nCLI Endpoints\n=============\n\nEach exposed CLI is added as an endpoint using the REST path of ``slicer_cli_web/<docker image tag and version>/<cli command>/run`` and also using the REST path of ``slicer_cli_web/<internal item id>/run``, where ``<docker image tag and version>`` is the combined tag and version with slashes, colons, and at signs replaced by underscores. All command line parameters can be passed as endpoint query parameters. Input items, folders, and files are specified by their Girder ID. Input images are specified by a Girder file ID. Output files are specified by name and with an associated parameter with the same name plus a ``_folder`` suffix with a Girder folder ID.\n\nSmall Example CLI Docker\n========================\n\nThe small example CLI docker image can be built locally via ``docker build --force-rm -t girder/slicer_cli_web:small .``, or pulled from Docker Hub.\n\nBatch Processing\n----------------\n\nAll CLIs that take any single item, image, or files as inputs can be run on a set of such resources from a single directory. For non-batch processing, the\nID of the image, item, or file is passed to ``<param>``. For batch processing, the ID of a folder is passed to ``<param>_folder`` and a regular expression is passed to <param>. All items in that folder whose name matches the regex are processed. For images, only items that contain large_images are considered. For files, the first file in each considered item is used.\n\nIf two inputs have batch specifications, there must be a one-to-one correspondence between the each of the lists of items determined by the folder ID and regular expression. All of the lists are enumerated sorted by the lower case item name.\n\nWhen running a batch job, a parent job initiates ordinary (non-batch) jobs. The parent job will only start another child job when the most recent child job is no longer waiting to start. This allows non-batch jobs or multiple batch jobs' children to naturally interleave. The parent job can be canceled which will stop it from scheduling any more child jobs.\n\nTemplated Inputs\n----------------\n\nAny CLI parameter that takes a value that isn't a Girder resource identifier can be specified with a Jinja2-style template string.\n\nFor instance, instead of typing an explicit output file name, one can specify something like ``{{title}}-{{reference_base}}-{{now}}{{extension}}``. If this were being run on a task called \"Radial Blur\" on an image called \"SampleImage.tiff\", where the output image referenced the image image and had a list of file extensions starting with \".png\", this would end up being converted to the value ``Radial Blur-SampleImage-20210428-084321.png``.\n\nThe following template values are handled identically for all parameters:\n\n- ``{{title}}``: the displayed CLI task title.\n- ``{{task}}``: the internal task name (this usually doesn't have spaces in it)\n- ``{{image}}``: the tag of the Docker image used for the task\n- ``{{now}}``: the local time the job started in the form yyyymmdd-HHMMSS. You can use ``yyyy``, ``mm``, ``dd``, ``HH``, ``MM``, ``SS`` for the four digit year, and two digit month, day, 24-hour, minute, and second.\n- ``{{parameter_<name of cli parameter>}}``: any parameter that isn't templated can be referenced by its name. For instance, in Example1 in the small-docker cli in this repo, ``{{parameter_stringChoice}}`` would get replaced by the value passed to the stringChoice parameter.\n- ``{{parameter_<name of cli parameter>_base}}`` is the same as the previous item except that if the right-most part of the parameter looks like a file extension, it is removed. This can be used to get the base name of file parameters.\n\nThe following template parameters are only handled on the web client:\n- ``{#control:<selector>#}``: If specified for the value of a parameter, use the value of the selected field from the DOM. For instance, ``{#control:.h-zoom-value#}`` could get the current image zoom level.\n\nThere are also template values specific to individual parameters:\n\n- ``{{name}}``: the name of this parameter. This usually doesn't have any spaces in it.\n- ``{{label}}``: the label of the is parameter. This is what is displayed in the user interface.\n- ``{{description}}``: the description of the parameter.\n- ``{{index}}``: the index, if any, of the parameter.\n- ``{{default}}``: the default value, if any, of the parameter.\n- ``{{extension}}``: the first entry in the ``fileExtension`` value of the parameter, if any.\n- ``{{reference}}``: if the parameter has a reference to another parameter, this returns that parameter's value. It is equivalent to ``{{parameter_<reference>}}``.\n- ``{{reference_base}}``: the reference value mentioned previously striped of the right-most file extension.\n\nIf the local (server) environment has any environment variables that begin with ``SLICER_CLI_WEB_``, these are accessible in the templates as ``{{env_(name)}}``. For instance, ``SLICER_CLI_WEB_DASK_SERVER`` would be accessible as ``{{env_DASK_SERVER}}``.\n\n.. |build-status| image:: https://circleci.com/gh/girder/slicer_cli_web.svg?style=svg\n :target: https://circleci.com/gh/girder/slicer_cli_web\n :alt: Build Status\n\n.. |codecov-io| image:: https://codecov.io/github/girder/slicer_cli_web/coverage.svg?branch=master\n :target: https://codecov.io/github/girder/slicer_cli_web?branch=master\n :alt: codecov.io\n\n.. _Girder: http://girder.readthedocs.io/en/latest/\n.. _Girder Worker: https://girder-worker.readthedocs.io/en/latest/\n.. _HistomicsTK: https://github.com/DigitalSlideArchive/HistomicsTK\n",
"bugtrack_url": null,
"license": "Apache Software License 2.0",
"summary": "A girder plugin for exposing slicer CLIs over the web",
"version": "1.5.4",
"project_urls": {
"Homepage": "https://github.com/girder/slicer_cli_web"
},
"split_keywords": [
"girder-plugin",
" slicer_cli_web"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "d25abfaf6f115710b3b03da8d50c2d73490e5b525aac7b0b5c2f9efca10f941a",
"md5": "f8ce3fd6c500130a48b20991e54a6800",
"sha256": "4179017a28feca00641b17c454c3d3a97e5b6816de7481e3182c3101acf86d7d"
},
"downloads": -1,
"filename": "girder_slicer_cli_web-1.5.4-py2.py3-none-any.whl",
"has_sig": false,
"md5_digest": "f8ce3fd6c500130a48b20991e54a6800",
"packagetype": "bdist_wheel",
"python_version": "py2.py3",
"requires_python": ">=3.8",
"size": 98061,
"upload_time": "2024-03-25T12:37:51",
"upload_time_iso_8601": "2024-03-25T12:37:51.599285Z",
"url": "https://files.pythonhosted.org/packages/d2/5a/bfaf6f115710b3b03da8d50c2d73490e5b525aac7b0b5c2f9efca10f941a/girder_slicer_cli_web-1.5.4-py2.py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "5c4742a56b0f22463a110c7c58b05dc0aea316b6350ca787a3bff27348c8e551",
"md5": "0964be8724c896ab9decf7378f0dba6f",
"sha256": "7058d97e971a7d31d7dd124f1befa114151ac21cde28395b1309d4aca9e3787d"
},
"downloads": -1,
"filename": "girder-slicer-cli-web-1.5.4.tar.gz",
"has_sig": false,
"md5_digest": "0964be8724c896ab9decf7378f0dba6f",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.8",
"size": 126162,
"upload_time": "2024-03-25T12:37:54",
"upload_time_iso_8601": "2024-03-25T12:37:54.498393Z",
"url": "https://files.pythonhosted.org/packages/5c/47/42a56b0f22463a110c7c58b05dc0aea316b6350ca787a3bff27348c8e551/girder-slicer-cli-web-1.5.4.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-03-25 12:37:54",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "girder",
"github_project": "slicer_cli_web",
"travis_ci": false,
"coveralls": false,
"github_actions": false,
"circle": true,
"tox": true,
"lcname": "girder-slicer-cli-web"
}
JSON
