Re: [easybuild] LUA modules: whatis statement split up across multiple lines when printed
Also partly related to that feature: I think it makes sense to include in the module whatis the list of extensions in bundles, so people can query it with “module key”. We currently do that manually, which is a pain…. Maybe I mention it already somewhere before? Damian On 23/01/17 10:49, "easybuild-requ...@lists.ugent.be on behalf of Alvarez, Damian" wrote: Related to this: Maybe it would be useful to add a small --dump-filter option, that simply dumps a list of easyconfigs (or a directory tree with them), but applying filters for it. For instance, if we want to share our setup, we might want to delete the contact field. Likewise for site specific things like usage. Something like “eb --dump-filter=contact,usage --dump-path=/tmp/dumped-ebs some_eb_repo” would be a generic and cleaner solution than having custom scripts for the same task. Just an idea. Damian On 20/01/17 20:20, "easybuild-requ...@lists.ugent.be on behalf of Kenneth Hoste" wrote: On 20/01/2017 10:49, Alvarez, Damian wrote: > I like it. I wanted actually to make PR including an extra “contact” field in the easyconfig file (we currently have it simply included in the description), but yours is way more complete. +1, this sounds like a very well worked out proposal providing lots of flexibility! I'd say be default we should try and provide meaningful (site-agnostic) information like this when we can in the easyconfigs we ship, and provide EB configuration options to optionally disable including that info in the generated modules. An effort like this would align well with a move to .yeb easyconfigs (long talked about, I know, but Alan has some plans to spend time to revive/stabilize this effort). > However, just as a side note, empty fields should not be created. Having an “usage section” that is empty is useless. If the a parameter is empty, the corresponding section should be left out entirely, of course. K. > > Damian > > On 20/01/17 10:10, "easybuild-requ...@lists.ugent.be on behalf of Markus Geimer" wrote: > > All, > > >> I have noticed a slightly annoying (if small) side effect of the move > >> to lua module files. Specifically, module help and whatis statements > >> will now be split up across multiple lines if they are so formatted in > >> the easyconfig. An example follows at the end of this message. > >> [...] > >> > >> This could be fixed, if desired, by removing all instances of the > >> following in descriptions: > >> > >> “””Some text > >> > >> Split up > >> > >> Into multiple lines””” > >> > >> And replacing it with: > >> > >> “Text all together on a single (probably long) line” > >> > >> Any thoughts in this regard? > >> > >> > > > > 1) if you syntax check with pep8 (recommended) it won't be > > happy with those long lines > > 2) causes all kinds of horizontal scroll issues on some viewers > > 3) there are reasons why I want to split it up. > > > > as a rule, I write > > > > description = """ > > first line of text up to 80 cols > > second line of text up to 80cols > > etc. > > """ > > > > I find it much cleaner. > > Like Jack, I'm (personally) also annoyed of those long lines in the > 'module help' output and like his approach of tackling this issue. > However, as usual there are different site policies, so maybe we need > to make things configurable. This is actually something that I have > in mind for quite some time, but never got round to propose it to the > community. Taking this discussion as a trigger, here are my thoughts: > > Currently, the output of `module help` (and `module whatis`) is > constructed out of two easyconfig parameters: `description` and > `homepage`. (The `whatis` output can also be overwritten using > the `whatis` easyconfig parameter.) Both are taken verbatim, > simply concatenated with a `-` as separator, and written into the > modulefile. The following proposal is intended to provide more > flexibility for site-specific customizations by introducing some
Re: [easybuild] LUA modules: whatis statement split up across multiple lines when printed
Related to this: Maybe it would be useful to add a small --dump-filter option, that simply dumps a list of easyconfigs (or a directory tree with them), but applying filters for it. For instance, if we want to share our setup, we might want to delete the contact field. Likewise for site specific things like usage. Something like “eb --dump-filter=contact,usage --dump-path=/tmp/dumped-ebs some_eb_repo” would be a generic and cleaner solution than having custom scripts for the same task. Just an idea. Damian On 20/01/17 20:20, "easybuild-requ...@lists.ugent.be on behalf of Kenneth Hoste" wrote: On 20/01/2017 10:49, Alvarez, Damian wrote: > I like it. I wanted actually to make PR including an extra “contact” field in the easyconfig file (we currently have it simply included in the description), but yours is way more complete. +1, this sounds like a very well worked out proposal providing lots of flexibility! I'd say be default we should try and provide meaningful (site-agnostic) information like this when we can in the easyconfigs we ship, and provide EB configuration options to optionally disable including that info in the generated modules. An effort like this would align well with a move to .yeb easyconfigs (long talked about, I know, but Alan has some plans to spend time to revive/stabilize this effort). > However, just as a side note, empty fields should not be created. Having an “usage section” that is empty is useless. If the a parameter is empty, the corresponding section should be left out entirely, of course. K. > > Damian > > On 20/01/17 10:10, "easybuild-requ...@lists.ugent.be on behalf of Markus Geimer" wrote: > > All, > > >> I have noticed a slightly annoying (if small) side effect of the move > >> to lua module files. Specifically, module help and whatis statements > >> will now be split up across multiple lines if they are so formatted in > >> the easyconfig. An example follows at the end of this message. > >> [...] > >> > >> This could be fixed, if desired, by removing all instances of the > >> following in descriptions: > >> > >> “””Some text > >> > >> Split up > >> > >> Into multiple lines””” > >> > >> And replacing it with: > >> > >> “Text all together on a single (probably long) line” > >> > >> Any thoughts in this regard? > >> > >> > > > > 1) if you syntax check with pep8 (recommended) it won't be > > happy with those long lines > > 2) causes all kinds of horizontal scroll issues on some viewers > > 3) there are reasons why I want to split it up. > > > > as a rule, I write > > > > description = """ > > first line of text up to 80 cols > > second line of text up to 80cols > > etc. > > """ > > > > I find it much cleaner. > > Like Jack, I'm (personally) also annoyed of those long lines in the > 'module help' output and like his approach of tackling this issue. > However, as usual there are different site policies, so maybe we need > to make things configurable. This is actually something that I have > in mind for quite some time, but never got round to propose it to the > community. Taking this discussion as a trigger, here are my thoughts: > > Currently, the output of `module help` (and `module whatis`) is > constructed out of two easyconfig parameters: `description` and > `homepage`. (The `whatis` output can also be overwritten using > the `whatis` easyconfig parameter.) Both are taken verbatim, > simply concatenated with a `-` as separator, and written into the > modulefile. The following proposal is intended to provide more > flexibility for site-specific customizations by introducing some > additional (but optional) easyconfig parameters. > > > usage > Generic (or potentially site-specific) usage instructions. This > may, for example include a brief description of the main commands, > environment variables that are provided by the modulefile, how to > include headers and link against a library, or that one has to be > part of a special UNIX group to be able to use a software package. > > Type: free-form text > > docpath > Path to documentation installed by the package, relative to > $EBROOT. > > Type: List of strings > >
Re: [easybuild] LUA modules: whatis statement split up across multiple lines when printed
On 01/20/17 20:17, Kenneth Hoste wrote: > On 20/01/2017 10:10, Markus Geimer wrote: >>> (unfortunately, I don't think EasyBuild has a tag for a "module load" >>> message). >> It should be fairly straightforward to support that as well (if >> you want to hard-code this into the modulefile rather than using >> Lmod's admin.list approach). > > This *is* already supported, see the 'modloadmsg' easyconfig parameter, Now that you're saying it... ;-) 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: m.gei...@fz-juelich.de 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
RE: [easybuild] LUA modules: whatis statement split up across multiple lines when printed
Hi Ward, Thank you for that suggestion. In the end, I was able to find an easier one through the use of echo statements. In any case, I will await the outcome of these discussions around splitting up the description, help and whatis statements. Cheers, Ben -Original Message- From: easybuild-requ...@lists.ugent.be [mailto:easybuild-requ...@lists.ugent.be] On Behalf Of Ward Poelmans Sent: Friday, 20 January 2017 9:54 p.m. To: easybuild@lists.ugent.be Subject: Re: [easybuild] LUA modules: whatis statement split up across multiple lines when printed On Thu, Jan 19, 2017 at 10:38 PM, Ben Roberts wrote: > This is a problem for me and my site as we prepare our lists of > modules by looking at the output of “module whatis”. While we could > post-process that output, it is somewhat tedious and error prone to > have to do so. The formatting may also be somewhat ugly in general > when users consult a module whatis. Why not use the json output of spider to process the list of modules? In principle, you can even write a class to let Lmod write json instead of bash/perl/... to the screen. But I agree with Jack. We try to limit the number of character on a line to 120. Ward
Re: [easybuild] LUA modules: whatis statement split up across multiple lines when printed
On 20/01/2017 10:49, Alvarez, Damian wrote: I like it. I wanted actually to make PR including an extra “contact” field in the easyconfig file (we currently have it simply included in the description), but yours is way more complete. +1, this sounds like a very well worked out proposal providing lots of flexibility! I'd say be default we should try and provide meaningful (site-agnostic) information like this when we can in the easyconfigs we ship, and provide EB configuration options to optionally disable including that info in the generated modules. An effort like this would align well with a move to .yeb easyconfigs (long talked about, I know, but Alan has some plans to spend time to revive/stabilize this effort). However, just as a side note, empty fields should not be created. Having an “usage section” that is empty is useless. If the a parameter is empty, the corresponding section should be left out entirely, of course. K. Damian On 20/01/17 10:10, "easybuild-requ...@lists.ugent.be on behalf of Markus Geimer" wrote: All, >> I have noticed a slightly annoying (if small) side effect of the move >> to lua module files. Specifically, module help and whatis statements >> will now be split up across multiple lines if they are so formatted in >> the easyconfig. An example follows at the end of this message. >> [...] >> >> This could be fixed, if desired, by removing all instances of the >> following in descriptions: >> >> “””Some text >> >> Split up >> >> Into multiple lines””” >> >> And replacing it with: >> >> “Text all together on a single (probably long) line” >> >> Any thoughts in this regard? >> >> > > 1) if you syntax check with pep8 (recommended) it won't be > happy with those long lines > 2) causes all kinds of horizontal scroll issues on some viewers > 3) there are reasons why I want to split it up. > > as a rule, I write > > description = """ > first line of text up to 80 cols > second line of text up to 80cols > etc. > """ > > I find it much cleaner. Like Jack, I'm (personally) also annoyed of those long lines in the 'module help' output and like his approach of tackling this issue. However, as usual there are different site policies, so maybe we need to make things configurable. This is actually something that I have in mind for quite some time, but never got round to propose it to the community. Taking this discussion as a trigger, here are my thoughts: Currently, the output of `module help` (and `module whatis`) is constructed out of two easyconfig parameters: `description` and `homepage`. (The `whatis` output can also be overwritten using the `whatis` easyconfig parameter.) Both are taken verbatim, simply concatenated with a `-` as separator, and written into the modulefile. The following proposal is intended to provide more flexibility for site-specific customizations by introducing some additional (but optional) easyconfig parameters. usage Generic (or potentially site-specific) usage instructions. This may, for example include a brief description of the main commands, environment variables that are provided by the modulefile, how to include headers and link against a library, or that one has to be part of a special UNIX group to be able to use a software package. Type: free-form text docpath Path to documentation installed by the package, relative to $EBROOT. Type: List of strings support Package-specific support/bug report e-mail address, e.g., "supp...@package.org" Type: Single string (or list?) contact Site-specific contact, e.g., "Jim Admin , +1 555 123 456" Type: Single string (or list?) The `module help` output of an artificial package `foo` may then look like this: - 8< -- 8< - 8< - 8< - 8< - 8< - 8< - % module help foo/1.0 Module Specific Help for "foo/1.0" - Description === The foo package provide some service that can be used to do something. Its purpose is still somewhat unclear. Usage = Run 'foo' without parameters to start the graphical user interface. To use the 'foo' library in your own applications, use -I$EBROOTFOO/include when compiling and -L$EBROOTFOO/lib -lfoo when linking. Alternatively, you can also use the 'foo-config' utility using the '--cppflags', '--ldflags' and '--libs' command-line options.
Re: [easybuild] LUA modules: whatis statement split up across multiple lines when printed
On 20/01/2017 10:10, Markus Geimer wrote: (unfortunately, I don't think EasyBuild has a tag for a "module load" message). It should be fairly straightforward to support that as well (if you want to hard-code this into the modulefile rather than using Lmod's admin.list approach). This *is* already supported, see the 'modloadmsg' easyconfig parameter, it's used in a handful of easyconfigs already. K.
Re: [easybuild] LUA modules: whatis statement split up across multiple lines when printed
Am I reading about one of the developments planned for the User Meeting? On 20 January 2017 at 11:03, Markus Geimer wrote: > On 01/20/17 10:49, Alvarez, Damian wrote: > > I like it. I wanted actually to make PR including an extra “contact” > > field in the easyconfig file (we currently have it simply included in > > the description), but yours is way more complete. However, just as a > > side note, empty fields should not be created. Having an “usage > > section” that is empty is useless. > > Sure. That was never intended. The example was more to show how a > "complete" output would look like. > > Markus > > > On 20/01/17 10:10, "easybuild-requ...@lists.ugent.be on behalf of > Markus Geimer" m.gei...@fz-juelich.de> wrote: > > > > All, > > > > >> I have noticed a slightly annoying (if small) side effect of the > move > > >> to lua module files. Specifically, module help and whatis > statements > > >> will now be split up across multiple lines if they are so > formatted in > > >> the easyconfig. An example follows at the end of this message. > > >> [...] > > >> > > >> This could be fixed, if desired, by removing all instances of the > > >> following in descriptions: > > >> > > >> “””Some text > > >> > > >> Split up > > >> > > >> Into multiple lines””” > > >> > > >> And replacing it with: > > >> > > >> “Text all together on a single (probably long) line” > > >> > > >> Any thoughts in this regard? > > >> > > >> > > > > > > 1) if you syntax check with pep8 (recommended) it won't be > > > happy with those long lines > > > 2) causes all kinds of horizontal scroll issues on some viewers > > > 3) there are reasons why I want to split it up. > > > > > > as a rule, I write > > > > > > description = """ > > > first line of text up to 80 cols > > > second line of text up to 80cols > > > etc. > > > """ > > > > > > I find it much cleaner. > > > > Like Jack, I'm (personally) also annoyed of those long lines in the > > 'module help' output and like his approach of tackling this issue. > > However, as usual there are different site policies, so maybe we need > > to make things configurable. This is actually something that I have > > in mind for quite some time, but never got round to propose it to the > > community. Taking this discussion as a trigger, here are my > thoughts: > > > > Currently, the output of `module help` (and `module whatis`) is > > constructed out of two easyconfig parameters: `description` and > > `homepage`. (The `whatis` output can also be overwritten using > > the `whatis` easyconfig parameter.) Both are taken verbatim, > > simply concatenated with a `-` as separator, and written into the > > modulefile. The following proposal is intended to provide more > > flexibility for site-specific customizations by introducing some > > additional (but optional) easyconfig parameters. > > > > > > usage > > Generic (or potentially site-specific) usage instructions. This > > may, for example include a brief description of the main > commands, > > environment variables that are provided by the modulefile, how to > > include headers and link against a library, or that one has to be > > part of a special UNIX group to be able to use a software > package. > > > > Type: free-form text > > > > docpath > > Path to documentation installed by the package, relative to > > $EBROOT. > > > > Type: List of strings > > > > support > > Package-specific support/bug report e-mail address, e.g., > > "supp...@package.org" > > > > Type: Single string (or list?) > > > > contact > > Site-specific contact, e.g., > > "Jim Admin , +1 555 123 456" > > > > Type: Single string (or list?) > > > > > > The `module help` output of an artificial package `foo` may then look > > like this: > > > > - 8< -- 8< - 8< - 8< - 8< - 8< - 8< - > > > > % module help foo/1.0 > > Module Specific Help for "foo/1.0" - > > > > Description > > === > > The foo package provide some service that can be used to do > something. > > Its purpose is still somewhat unclear. > > > > Usage > > = > > Run 'foo' without parameters to start the graphical user interface. > > > > To use the 'foo' library in your own applications, use > > -I$EBROOTFOO/include > > when compiling and > > -L$EBROOTFOO/lib -lfoo > > when linking. Alternatively, you can also use the 'foo-config' > utility > > using the '--cppflags', '--ldflags' and '--libs' command-line > options. > > > > More information > > > >- Homepage: http://www.foo.org > >
Re: [easybuild] LUA modules: whatis statement split up across multiple lines when printed
On 01/20/17 10:49, Alvarez, Damian wrote: > I like it. I wanted actually to make PR including an extra “contact” > field in the easyconfig file (we currently have it simply included in > the description), but yours is way more complete. However, just as a > side note, empty fields should not be created. Having an “usage > section” that is empty is useless. Sure. That was never intended. The example was more to show how a "complete" output would look like. Markus > On 20/01/17 10:10, "easybuild-requ...@lists.ugent.be on behalf of Markus > Geimer" m.gei...@fz-juelich.de> wrote: > > All, > > >> I have noticed a slightly annoying (if small) side effect of the move > >> to lua module files. Specifically, module help and whatis statements > >> will now be split up across multiple lines if they are so formatted in > >> the easyconfig. An example follows at the end of this message. > >> [...] > >> > >> This could be fixed, if desired, by removing all instances of the > >> following in descriptions: > >> > >> “””Some text > >> > >> Split up > >> > >> Into multiple lines””” > >> > >> And replacing it with: > >> > >> “Text all together on a single (probably long) line” > >> > >> Any thoughts in this regard? > >> > >> > > > > 1) if you syntax check with pep8 (recommended) it won't be > > happy with those long lines > > 2) causes all kinds of horizontal scroll issues on some viewers > > 3) there are reasons why I want to split it up. > > > > as a rule, I write > > > > description = """ > > first line of text up to 80 cols > > second line of text up to 80cols > > etc. > > """ > > > > I find it much cleaner. > > Like Jack, I'm (personally) also annoyed of those long lines in the > 'module help' output and like his approach of tackling this issue. > However, as usual there are different site policies, so maybe we need > to make things configurable. This is actually something that I have > in mind for quite some time, but never got round to propose it to the > community. Taking this discussion as a trigger, here are my thoughts: > > Currently, the output of `module help` (and `module whatis`) is > constructed out of two easyconfig parameters: `description` and > `homepage`. (The `whatis` output can also be overwritten using > the `whatis` easyconfig parameter.) Both are taken verbatim, > simply concatenated with a `-` as separator, and written into the > modulefile. The following proposal is intended to provide more > flexibility for site-specific customizations by introducing some > additional (but optional) easyconfig parameters. > > > usage > Generic (or potentially site-specific) usage instructions. This > may, for example include a brief description of the main commands, > environment variables that are provided by the modulefile, how to > include headers and link against a library, or that one has to be > part of a special UNIX group to be able to use a software package. > > Type: free-form text > > docpath > Path to documentation installed by the package, relative to > $EBROOT. > > Type: List of strings > > support > Package-specific support/bug report e-mail address, e.g., > "supp...@package.org" > > Type: Single string (or list?) > > contact > Site-specific contact, e.g., > "Jim Admin , +1 555 123 456" > > Type: Single string (or list?) > > > The `module help` output of an artificial package `foo` may then look > like this: > > - 8< -- 8< - 8< - 8< - 8< - 8< - 8< - > > % module help foo/1.0 > Module Specific Help for "foo/1.0" - > > Description > === > The foo package provide some service that can be used to do something. > Its purpose is still somewhat unclear. > > Usage > = > Run 'foo' without parameters to start the graphical user interface. > > To use the 'foo' library in your own applications, use > -I$EBROOTFOO/include > when compiling and > -L$EBROOTFOO/lib -lfoo > when linking. Alternatively, you can also use the 'foo-config' utility > using the '--cppflags', '--ldflags' and '--libs' command-line options. > > More information > >- Homepage: http://www.foo.org >- Local documentation: > - $EBROOTFOO/share/doc/foo/UserGuide.pdf > - $EBROOTFOO/share/doc/foo/html/index.html >- Support/bug reports: supp...@foo.org >- Contact: Jim Admin , +1 555 123 456 > > - >8 - >8 - >8 - >8 - >8 -
Re: [easybuild] LUA modules: whatis statement split up across multiple lines when printed
I like it. I wanted actually to make PR including an extra “contact” field in the easyconfig file (we currently have it simply included in the description), but yours is way more complete. However, just as a side note, empty fields should not be created. Having an “usage section” that is empty is useless. Damian On 20/01/17 10:10, "easybuild-requ...@lists.ugent.be on behalf of Markus Geimer" wrote: All, >> I have noticed a slightly annoying (if small) side effect of the move >> to lua module files. Specifically, module help and whatis statements >> will now be split up across multiple lines if they are so formatted in >> the easyconfig. An example follows at the end of this message. >> [...] >> >> This could be fixed, if desired, by removing all instances of the >> following in descriptions: >> >> “””Some text >> >> Split up >> >> Into multiple lines””” >> >> And replacing it with: >> >> “Text all together on a single (probably long) line” >> >> Any thoughts in this regard? >> >> > > 1) if you syntax check with pep8 (recommended) it won't be > happy with those long lines > 2) causes all kinds of horizontal scroll issues on some viewers > 3) there are reasons why I want to split it up. > > as a rule, I write > > description = """ > first line of text up to 80 cols > second line of text up to 80cols > etc. > """ > > I find it much cleaner. Like Jack, I'm (personally) also annoyed of those long lines in the 'module help' output and like his approach of tackling this issue. However, as usual there are different site policies, so maybe we need to make things configurable. This is actually something that I have in mind for quite some time, but never got round to propose it to the community. Taking this discussion as a trigger, here are my thoughts: Currently, the output of `module help` (and `module whatis`) is constructed out of two easyconfig parameters: `description` and `homepage`. (The `whatis` output can also be overwritten using the `whatis` easyconfig parameter.) Both are taken verbatim, simply concatenated with a `-` as separator, and written into the modulefile. The following proposal is intended to provide more flexibility for site-specific customizations by introducing some additional (but optional) easyconfig parameters. usage Generic (or potentially site-specific) usage instructions. This may, for example include a brief description of the main commands, environment variables that are provided by the modulefile, how to include headers and link against a library, or that one has to be part of a special UNIX group to be able to use a software package. Type: free-form text docpath Path to documentation installed by the package, relative to $EBROOT. Type: List of strings support Package-specific support/bug report e-mail address, e.g., "supp...@package.org" Type: Single string (or list?) contact Site-specific contact, e.g., "Jim Admin , +1 555 123 456" Type: Single string (or list?) The `module help` output of an artificial package `foo` may then look like this: - 8< -- 8< - 8< - 8< - 8< - 8< - 8< - % module help foo/1.0 Module Specific Help for "foo/1.0" - Description === The foo package provide some service that can be used to do something. Its purpose is still somewhat unclear. Usage = Run 'foo' without parameters to start the graphical user interface. To use the 'foo' library in your own applications, use -I$EBROOTFOO/include when compiling and -L$EBROOTFOO/lib -lfoo when linking. Alternatively, you can also use the 'foo-config' utility using the '--cppflags', '--ldflags' and '--libs' command-line options. More information - Homepage: http://www.foo.org - Local documentation: - $EBROOTFOO/share/doc/foo/UserGuide.pdf - $EBROOTFOO/share/doc/foo/html/index.html - Support/bug reports: supp...@foo.org - Contact: Jim Admin , +1 555 123 456 - >8 - >8 - >8 - >8 - >8 - >8 - >8 - Instead, `module whatis` would only print the description: - 8< -- 8< - 8< - 8< - 8< - 8< - 8< - % module whatis foo/1.0 foo/1.0 : Description: The foo package provide some service that can be used to do something. Its purpose is still somewhat unclear. - >8 - >8 - >8 - >8 - >8 - >8 - >8 ---
Re: [easybuild] LUA modules: whatis statement split up across multiple lines when printed
All, >> I have noticed a slightly annoying (if small) side effect of the move >> to lua module files. Specifically, module help and whatis statements >> will now be split up across multiple lines if they are so formatted in >> the easyconfig. An example follows at the end of this message. >> [...] >> >> This could be fixed, if desired, by removing all instances of the >> following in descriptions: >> >> “””Some text >> >> Split up >> >> Into multiple lines””” >> >> And replacing it with: >> >> “Text all together on a single (probably long) line” >> >> Any thoughts in this regard? >> >> > > 1) if you syntax check with pep8 (recommended) it won't be > happy with those long lines > 2) causes all kinds of horizontal scroll issues on some viewers > 3) there are reasons why I want to split it up. > > as a rule, I write > > description = """ > first line of text up to 80 cols > second line of text up to 80cols > etc. > """ > > I find it much cleaner. Like Jack, I'm (personally) also annoyed of those long lines in the 'module help' output and like his approach of tackling this issue. However, as usual there are different site policies, so maybe we need to make things configurable. This is actually something that I have in mind for quite some time, but never got round to propose it to the community. Taking this discussion as a trigger, here are my thoughts: Currently, the output of `module help` (and `module whatis`) is constructed out of two easyconfig parameters: `description` and `homepage`. (The `whatis` output can also be overwritten using the `whatis` easyconfig parameter.) Both are taken verbatim, simply concatenated with a `-` as separator, and written into the modulefile. The following proposal is intended to provide more flexibility for site-specific customizations by introducing some additional (but optional) easyconfig parameters. usage Generic (or potentially site-specific) usage instructions. This may, for example include a brief description of the main commands, environment variables that are provided by the modulefile, how to include headers and link against a library, or that one has to be part of a special UNIX group to be able to use a software package. Type: free-form text docpath Path to documentation installed by the package, relative to $EBROOT. Type: List of strings support Package-specific support/bug report e-mail address, e.g., "supp...@package.org" Type: Single string (or list?) contact Site-specific contact, e.g., "Jim Admin , +1 555 123 456" Type: Single string (or list?) The `module help` output of an artificial package `foo` may then look like this: - 8< -- 8< - 8< - 8< - 8< - 8< - 8< - % module help foo/1.0 Module Specific Help for "foo/1.0" - Description === The foo package provide some service that can be used to do something. Its purpose is still somewhat unclear. Usage = Run 'foo' without parameters to start the graphical user interface. To use the 'foo' library in your own applications, use -I$EBROOTFOO/include when compiling and -L$EBROOTFOO/lib -lfoo when linking. Alternatively, you can also use the 'foo-config' utility using the '--cppflags', '--ldflags' and '--libs' command-line options. More information - Homepage: http://www.foo.org - Local documentation: - $EBROOTFOO/share/doc/foo/UserGuide.pdf - $EBROOTFOO/share/doc/foo/html/index.html - Support/bug reports: supp...@foo.org - Contact: Jim Admin , +1 555 123 456 - >8 - >8 - >8 - >8 - >8 - >8 - >8 - Instead, `module whatis` would only print the description: - 8< -- 8< - 8< - 8< - 8< - 8< - 8< - % module whatis foo/1.0 foo/1.0 : Description: The foo package provide some service that can be used to do something. Its purpose is still somewhat unclear. - >8 - >8 - >8 - >8 - >8 - >8 - >8 - For the free-form text fields, we could implement some sort of automatic line wrapping to a configurable width limit (including 'none'). Python's `textwrap` functionality may serve as a starting point, however, it has several limitations (only single paragraph, need to use `dedent` to be useful, ...). So we probably need some preprocessing to support, e.g., multiple paragraphs, (sub-)section headings, bullet lists, etc. (kind of a markdown processing). What do you think? > (unfortunately, I don't think EasyBuild has a tag for a "module load" > message). It should be fairly straightforward to support that as well (if you want to hard-code this into the modulefile rather than using Lmod's admin.list approach). 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
Re: [easybuild] LUA modules: whatis statement split up across multiple lines when printed
On Thu, Jan 19, 2017 at 10:38 PM, Ben Roberts wrote: > This is a problem for me and my site as we prepare our lists of modules by > looking at the output of “module whatis”. While we could post-process that > output, it is somewhat tedious and error prone to have to do so. The > formatting may also be somewhat ugly in general when users consult a module > whatis. Why not use the json output of spider to process the list of modules? In principle, you can even write a class to let Lmod write json instead of bash/perl/... to the screen. But I agree with Jack. We try to limit the number of character on a line to 120. Ward
Re: [easybuild] LUA modules: whatis statement split up across multiple lines when printed
On 01/19/2017 03:38 PM, Ben Roberts wrote: All, I have noticed a slightly annoying (if small) side effect of the move to lua module files. Specifically, module help and whatis statements will now be split up across multiple lines if they are so formatted in the easyconfig. An example follows at the end of this message. This is a problem for me and my site as we prepare our lists of modules by looking at the output of “module whatis”. While we could post-process that output, it is somewhat tedious and error prone to have to do so. The formatting may also be somewhat ugly in general when users consult a module whatis. This could be fixed, if desired, by removing all instances of the following in descriptions: “””Some text Split up Into multiple lines””” And replacing it with: “Text all together on a single (probably long) line” Any thoughts in this regard? 1) if you syntax check with pep8 (recommended) it won't be happy with those long lines 2) causes all kinds of horizontal scroll issues on some viewers 3) there are reasons why I want to split it up. as a rule, I write description = """ first line of text up to 80 cols second line of text up to 80cols etc. """ I find it much cleaner. As a demonstration for 3) I was working on an easyconfig yesterday for Intel's Python and used it like this: description = """ Intel® Distribution for Python. Powered by Anaconda. Accelerating Python* performance on modern architectures from Intel. To activate virtual environment (for user modules), run: source $PYACTIVATE """ That way the message on activating is distinct from the description (unfortunately, I don't think EasyBuild has a tag for a "module load" message). My. $.02 jack
