I agree that "module avail" should primarily focus on performance and
therefore not look for variants by default.
Nevertheless this option could be very useful, especially in setups where
this technique is used a lot, so there should definitely be (even in the
long term) an option to allow such queries.
Probably adding a switch to the "module avail" command would be the best
option as in this case the user knows that more time will be needed to
perform the query and/or the search and in such cases performance will be
less of an issue.
Just my 2c.
Roberto
On Tue, Aug 17, 2021 at 7:36 AM Xavier Delaruelle <
xav...@gm...> wrote:
> Hi Nick,
>
> Currently you cannot "see" the variant through "module avail". "module
> show <modulename>" has to be use to see the variant commands written
> inside modulefile:
>
> $ ml show foo +bar
> -------------------------------------------------------------------
> /path/to/modulefiles/foo/1.0:
>
> variant --boolean bar
> -------------------------------------------------------------------
>
> However it currently requires to pass a value to all variant without a
> default value set to evaluate correctly otherwise an error is
> obtained, like in the below test. I will see if I can change this
> behavior for Modules 5.0 to allow to omit variant specification when
> displaying the content of the modulefile [1].
>
> $ ml show foo
> -------------------------------------------------------------------
> /path/to/modulefiles/foo/1.0:
>
> variant --boolean bar
> ERROR: No value specified for variant 'bar'
> Allowed values are: 1 0 yes no true false on off
> -------------------------------------------------------------------
>
> Regarding "module avail", variant are not reported currently as
> modulefiles are not evaluated during an avail command. This is
> something that can be changed in the future, especially for different
> search use cases you exposed. But this should be made with care
> regarding performances. Maybe variant should not be reported on a
> global "module avail" (to avoid the evaluation of all the modulefiles
> and also to limit the quantity of information transmitted to the
> user). Then doing a "module avail mod" would trigger the evaluation of
> all modulefiles matching "mod" then returning all the available
> variant of the matching modules. Need to think of a way of reporting
> such information in an output that can still be efficiently understood
> by users.
>
> Please go ahead and open issues, one for having the variant reported
> on a "module avail" and another to be able to specify a variant value
> to search in all available modulefiles (ml av compiler=gcc/9). Both
> issues will not be addressed quickly as they require a big amount of
> work, but I will work on this direction.
>
> Regards,
> Xavier
>
> [1] https://github.com/cea-hpc/modules/issues/406
>
> Le ven. 13 août 2021 à 15:02, Nick Papior <nic...@gm...> a écrit :
> >
> > To add to this.
> >
> > It might be cool to also get all modules that match a certain variant
> value
> >
> > say
> >
> > ml av compiler=gcc/9
> >
> > would list all modules with variants named compiler and the possible
> value gcc/9?
> >
> > Let me know if I should open an issue?
> >
> > Den fre. 13. aug. 2021 kl. 14.59 skrev Nick Papior <nic...@gm...
> >:
> >>
> >> Hi,
> >>
> >> How can users see which variants and values are accessible with "module
> avail".
> >>
> >> I tried:
> >>
> >> ml av -l
> >> ml av --indepth
> >>
> >> neither showed anything related to variants.
> >> First when I have loaded a module can I see which variants are
> available, but here I can't see which values of the variants are available?
> >>
> >> Suggestion:
> >>
> >> ml av -l (lists all default variants for modules)
> >> ml av -l <module> (lists all default variants + possible values)
> >>
> >> Or is there another way to do this?
> >>
> >> --
> >> Kind regards Nick
> >
> >
> >
> > --
> > Kind regards Nick
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>
|