Implementing a case statement in form.yml.erb

I want to assign the appropriate tensorflow for the JupyterLab module selected.
I’ve tried using the ‘data-options-for-modules-JupyterLab/3.1.6: false/true’ approach in form.yml without any success.

So it occured to try and step up to the extended ruby usage in our form.yml (form.yml.erb). So, is this a good idea? If it’s not a bad idea, should the following implement what I’m looking for? The following currently breaks my ood session

32 modules:
33 label: “Select module for Jupyter version”
34 widget: select
35 options:
36 - [ “JupyterLab/3.1.6”, “JupyterLab/3.1.6-GCCcore-11.2.0” ]
37 - [ “JupyterLab/3.2.8”, “JupyterLab/3.2.8-GCCcore-10.3.0” ]
38 extra_jupyter_args: “”
39 accessmod:
40 <%- case modules
41 when “Jupyter/3.1.6”
42 value: “TensorFlow/2.7.1-foss-2021b-CUDA-11.4.1”
43 else
44 value: “TensorFlow/2.6.0-foss-2021a-CUDA-11.3.1”
45 end
46 %>

All I really want to do is use the ‘data-option-for’ feature, which works sometimes, and not others. The implementation that works well is the first quoted block. For the choice of partition, the available node_type is restricted to those that make sense. In addition, the ‘data-hide’ method is used to suppress the number of gpus when the partition does not support gpu nodes. In the second block, I try to apply the same idea to module selection, where my module system has EasyBuild toolchains – and I don’t want to have requests to mix toolchains at load time. Why that is not working is beyond my capabilities at the moment.

69 num_gpu:
70 label: “GPU [1 or 2] – optional field, leave 0 unless asking for node with gpus”
71 widget: “number_field”
72 required: false
73 value: 0
74 min: 0
75 max: 2
76 node_type:
77 label: “Node Type: batch, gpu for research; class(c) - specific course groups only)”
78 widget: select
79 options:
80 - [ “batch”, “batch”,
81 data-hide-num-gpu: true ]
82 - [ “gpu”, “gpu” ]
83 - [ “aisc”, “aisc” ]
84 type_constraint:
85 label: “Node Features”
86 help: |
87 - Uses the ‘-C’ flag to select gpu or cpu node capabilities
88 widget: select
89 options:
90 - [ “Next available cpu node”, “icosa192gb|icosa256gb”,
91 data-option-for-node-type-gpu: false,
92 data-option-for-node-type-aisc: false,
93 ]
94 - [ “Pioneer: icosa192gb”, “icosa192gb”,
95 data-option-for-node-type-gpu: false,
96 data-option-for-node-type-aisc: false,
97 data-max-job-mem-for-type-constraint-icosa192gb: 186, ]
98 - [ “Pioneer: icosa256gb”, “icosa256gb”,
99 data-option-for-node-type-gpu: false,
100 data-option-for-node-type-aisc: false,
101 data-max-job-mem-for-type-constraint-icosa192gb: 250, ]
102 - [ “Next available gpu 2080, p100 or v100 node”, “gpu2080|gpup100|gpu2v100”,
103 data-option-for-node-type-batch: false,
104 data-option-for-node-type-aisc: false,]
105 - [ “Pioneer: gpu2v100”, “gpu2v100”,
106 data-option-for-node-type-batch: false,
107 data-option-for-node-type-aisc: false,
108 data-max-job-mem-for-type-constraint-gpu2v100: 188, ]
109 - [ “Pioneer: gpup100”, “gpup100”,
110 data-option-for-node-type-batch: false,
111 data-option-for-node-type-aisc: false,
112 data-max-job-mem-for-type-constraint-gpup100: 186, ]
113 - [ “Pioneer: gpu2080”, “gpu2080”,
114 data-option-for-node-type-batch: false,
115 data-option-for-node-type-aisc: false,
116 data-max-job-mem-for-type-constraint-gpu2080: 125, ]

And for the code working not, I’ve tried different attribute names, adjusting the single- vs double-quotes…i don’t see why this is failing to reduce the number of options presented, because the code above does just that. In producing the above code, I did not that the syntax requirements are pretty finicky, so perhaps there’s something obvious to someone else.

121 jupyter_ver:
122 label: “Select module for Jupyter version”
123 widget: select
124 options:
125 - [ ‘6’, ‘JupyterLab/3.1.6-GCCcore-11.2.0’ ]
126 - [ ‘8’, ‘JupyterLab/3.2.8-GCCcore-10.3.0’ ]
127 # - [ “JupyterLab/3.1.6”, “JupyterLab/3.1.6-GCCcore-11.2.0” ]
128 # - [ “JupyterLab/3.2.8”, “JupyterLab/3.2.8-GCCcore-10.3.0” ]
129 # extra_jupyter_args: “”
130 accessmod:
131 label: “Choose Tensorflow to match the toolchain supporting JupyterLab”
132 widget: select
133 options:
134 - [
135 ‘TensorFlow/2.6.0-foss-2021a-CUDA-11.3.1’, ‘TensorFlow/2.6.0-foss-2021a-CUDA-11.3.1’,
136 data-option-for-jupyter-ver-8: true,
137 data-option-for-jupyter-ver-6: false
138 ]
139 - [
140 ‘TensorFlow/2.7.1-foss-2021b-CUDA-11.4.1’, ‘TensorFlow/2.7.1-foss-2021b-CUDA-11.4.1’,
141 data-option-for-jupyter-ver-6: true,
142 data-option-for-jupyter-ver-8: false
143 ]

Can you attach the yml file directly to the topic? I think that may help a bit with all the formatting there.

There’s a lot to go through here - could you rephrase the problem statement a little simpler? I.e., I want accessmod to change options for jupyter_ver.

Likely not - but if looks like you answered yourself. You need the data- options for javascript to update the page. All Ruby ERB is rendered server side - so it doesn’t create the dynamic behavior you want because that’s all client side javascript.

The goal is to use the dynamic form(js) such that the choice of jupyter version limits the options presented under accessmod. Lines 125-128 just reflect trying a short label (125-6) in the event it’s the label that is used as the case of the ‘data-option-for’.

I’ll try to remember how to attach a file.

Cool. Drag and drop should work, but here’s this button too.

notworking_form.yml (5.4 KB)
working_form.yml (3.9 KB)

There’s a bug on our side where we don’t like the / in your variable names (specifically JupyterLab/3.1.6-...).

Replace JupyterLab/... with JupyterLab-... and it should work.

  jupyter_ver:
    label: "Select module for Jupyter version"
    widget: select
    options:
      - [ '6', 'JupyterLab-3.1.6-GCCcore-11.2.0' ]
      - [ '8', 'JupyterLab-3.2.8-GCCcore-10.3.0' ]
  accessmod:
    label: "Choose Tensorflow to match the toolchain supporting JupyterLab"
    widget: select
    options:
      - [
          'TensorFlow/2.6.0-foss-2021a-CUDA-11.3.1', 'TensorFlow/2.6.0-foss-2021a-CUDA-11.3.1',
          data-option-for-jupyter-ver-JupyterLab-3.2.8-GCCcore-10.3.0: false,
        ]
      - [
          'TensorFlow/2.7.1-foss-2021b-CUDA-11.4.1', 'TensorFlow/2.7.1-foss-2021b-CUDA-11.4.1',
          data-option-for-jupyter-ver-JupyterLab-3.1.6-GCCcore-11.2.0: false,
        ]

Then assuming you had something like this in your script.sh.erb you can make this replacement back to slashes:

# script.sh.erb - replace 
# <%= jupyter_ver %>
# with
<%= jupyter_ver.gsub("JupyterLab-", "JupyterLab/") %>

Also you don’t need to set data-option-for to true. Everything is an option for everything else by default. So you only need to set stuff to false to hide options.

data-option-for-jupyter-ver-JupyterLab/3.1.6-GCCcore-11.2.0: true,

@emily.dragowsky I’ve fixed this bug in 2.0.29 which will be out sometime next week.