auto_modules_<MODULE_NAME> label?

Hi!

I’m trying to update our interactive applications to take advantage of the new automatic form options, especially auto_modules and I have a couple questions:

First, it took me quite a while to realize that the JSON module list that module_file_dir points to needed to be named after the cluster name defined in config/clusters.d. Retrospectively, it makes sense, but maybe a note in the documentation, for the module_file_dir configuration property, would be helpful and save time for other users? :slight_smile:

Then, I’m not really sure how to customize the widget label for auto_modules. I have this in my form.yml:

form:
  - auto_modules_python

attributes:
  auto_modules_python
    label: "custom label for Python"

but the app form shows the label as “Auto modules (none given)”, instead of my custom label. Is it expected?

Thanks!

Thanks for the feedback - I’ll make a ticket for the same directly.

I do know that they’re case sensitive - so python is different than Python (another thing that needs documented!). That’s what I would guess off the top (I had this issue with our R modules).

Thanks @jeff.ohrstrom !

For the label question, it doesn’t seem related to capitalization, our python modules are all lower case.

To clarify, using the example configuration in my first post, auto_modules_python works and correctly display a widget with the list of our Python module versions. It’s just the widget label that defaults to ‘Auto modules (none given)’ instead of using the label attribute from the form.yml file:
image

Sorry! Yea I think you just found a bug.

What we have is here:

It should actually have () around the 2nd operand. You can edit your production file if you like. I’ll submit a patch shortly but since we’re close to 3.1 I don’t know if there’ll be a 3.0.4 (unless there are more bugs!)

 @opts[:label] || (@hpc_module.nil? ? 'Auto modules (none given)' : "#{@hpc_module.titleize} version")

Ah right, that makes sense.
Thanks for confirming the issue and providing a quick fix, much appreciated!

I have a pull request in to fix it that I’ll backport to 3.0. Though, that said - it’ll take a few more bugs/patches for us to release 3.0.4, so I don’t know if the patch will make it’s way to you until 3.1 or what.

1 Like

I have another feature/enhancement suggestion, not too sure how it’s achievable, but at the moment, when the list of available module versions includes “default”, there’s no way to tell which version if the default one. Maybe adding a little indicator next to the default version number, or the explicit version number next to the “default” label could be helpful?

Yea I can file the ticket. I’ll have to check lmod spider output to see if it actually indicates what version is default though (I’m not 100% sure if it does).