On 02/15/17 09:20, Ward Poelmans wrote:
> On 14-02-17 20:08, Kenneth Hoste wrote:
>>
>> I feel this sort of terse key/value style could be useful, but only for
>> single-line info (e.g. homepage, contact, etc.).
I (personally) totally agree with that. I have always considered
'module whatis' to be a command to get a brief overview of the
package (i.e., a terse single-line description, the homepage, and
contact information), while 'module help' provides more detailed
documentation with all bells and whistles. In addition, 'whatis'
strings include everything that should be searchable by 'keyword',
e.g., a list of extensions. However, in many cases this would
be a rather long one-liner...
If you include things like 'usage' and 'examples' also as a
'whatis' string, the 'whatis' and 'help' commands are basically
identical except for the formatting of the output. This doesn't
make much sense to me.
>> For things like 'description' and 'usage', I'm not sure this would be
>> useful or sensible.
The thing with 'description' is that 'module spider' uses the
'Description:' prefix to determine which 'whatis' line to show
in the 'module spider foo' output (taken from one specific
'foo' module file -- no clue which one). So again, a short,
rather generic one-liner description would make the most sense
to me here, as the more specific 'module spider foo/42' output
prints the full help text of this particular version. Currently
this just repeats the description. If we distinguish between
the "whatis description" and the "help description", they could
be different -- with the help stuff being more detailed. For
example:
whatis-description (all versions):
GROMACS is a versatile molecular dynamics package
help-description (e.g., 5.0-CUDA):
GROMACS is a high-performance molecular dynamics
package supporting all the usual algorithms [...]
This package has been built with CUDA support.
I guess you get the idea. But this may break scripts people are
using to generate their web pages, so I'm not sure how to proceed
here...
>> So, maybe what you're looking for is some hybrid approach, where aspects
>> like 'description' and 'usage' (and 'examples') are properly fleshed out
>> sections, where all the other info is packed together in an easy to
>> digest (for machines) form, like the key-value style you showed.
>
> I don't really agree with that. The output show be nicely human
> readably. If you want to parse it, we should let Lmod output json (or
> some other serialization format). I wouldn't bother too much with making
> it both human + machine readable at the same time.
Since there is already disagreement, there is probably no way
around some form of templating. But to be honest, I'm not up
for that...
Markus
--
Dr. Markus Geimer
Juelich Supercomputing Centre
Institute for Advanced Simulation
Forschungszentrum Juelich GmbH
52425 Juelich, Germany
Phone: +49-2461-61-1773
Fax: +49-2461-61-6656
E-mail: [email protected]
WWW: http://www.fz-juelich.de/jsc/
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
