I think there is no reason to break backwards compatibility. But we still can make it better adding templates like %(pyver)s and allowing whatis to be defined using them. For instance:
whatis = ["Homepage: %s" % homepage, "Description: %s" % description, “List of extensions: %(extension_list)s”] Note how extension_list has to be a template, as it is computed by easybuild, while homepage and description are easyconfig parameters that can be treated as “variables” directly on the easyconfig file. As Markus and I discussed yesterday, one can think about adding stuff like short_description to easyconfigs, to allow greater future flexibility. This allows a great deal of site customization without breaking backwards compatibility. Damian On 03/07/17 18:50, "Kenneth Hoste" <[email protected]> wrote: (excluding lmod-users in CC) On 03/07/2017 14:37, Alvarez, Damian wrote: > This is probably a discussion more for the easybuild mailing list (in CC now). > > Avoiding autogenerated “whatis” lines is fine IMO, as long as it does not affect the autogenerated “help” lines. That’s actually kind of the whole point, being able to control what is included in “whatis”, which should be a oneliner kind of thing (ok, it might be longer, but it shouldn’t be a full blown “help”). That’s at least how I envision the implementation of the suggestion that my [other] colleagues made to me last week. > > Also, I am talking here about our particular case, I am not sure if this is something that should be considered for the upstream EB repos. Maybe changing “whatis” upstream would break other’s setup, I am not sure. On the other hand, having an autogenerated “whatis” being exactly the same as the autogenerated “help” is kind of weird. I recall it was discussed already on the past, but I don’t remember the outcome of the discussion. I think the current 'whatis' support is sufficient, but I'm fine with making it 'smarter' like Markus suggested below. In any case, we should keep current default behavior as-is, i.e. retaining backward compatibility. If there are sufficient reasons to switch to other behavior, we can consider that for EasyBuild v4.0 though.... regards, Kenneth > > Damian > > On 03/07/17 13:42, "Geimer, Markus" <[email protected]> wrote: > > Damian, all, > > Keep in mind that when using the 'whatis' easyconfig parameter, *all* > auto-generated whatis lines (description, homepage, extensions if any) > will be suppressed. > > @Kenneth: Maybe we need to consider the whatis lines as key/value > pairs, allowing to suppress (empty value) or overwrite (non-empty > value) auto-generated whatis entries? > > Markus > > > On 07/03/2017 12:25 PM, Alvarez, Damian wrote: > > Let me expand a bit on the background of my question: > > > > > > > > At the moment, our modules are generated by EasyBuild, and include a > > long "whatis” string, and a long “help” string. These strings are > > autogenerated, and what EB does is making them exactly the same, if no > > specific “whatis” string is specified. > > > > > > > > Some colleagues were complaining, saying that they want to see a very > > short description when spidering, and a very long description when using > > “ml help”. I said that we could do it, by specifying a short “whatis” > > string on the EB files. I was expecting “ml spider” to show the contents > > of “whatis”, not of “help”. I did a small experiment, and I found out > > that I was wrong: > > > > > > > > ~]$ ml show test1 > > > > ------------------------------- > > > > /path/to/test1/1.0.lua: > > > > ------------------------------- > > > > whatis("whatis") > > > > help([[help]]) > > > > > > > > ~]$ ml spider test1 > > > > > > > > ------------------------------- > > > > test1: test1/1.0 > > > > ------------------------------- > > > > > > > > This module can be loaded directly: module load test1/1.0 > > > > > > > > Help: > > > > help > > > > > > > > After Rob’s first email I now understand that I can “trick” lmod and > > make spider print the content of “whatis”: > > > > > > > > ~]$ ml show test1 > > > > ------------------------------- > > > > /path/to/test1/1.0.lua: > > > > ------------------------------- > > > > whatis("Description: whatis") > > > > help([[help]]) > > > > > > > > ~]$ ml spider test1 > > > > > > > > ------------------------------- > > > > test1: test1/1.0 > > > > ------------------------------- > > > > Description: > > > > whatis > > > > > > > > > > > > This module can be loaded directly: module load test1/1.0 > > > > > > > > Help: > > > > help > > > > > > > > > > > > That gets closer to what my colleagues suggested. However, we still get > > the full “help” string, which they’d like to avoid when using spider. > > But I’ve seen too that the spider will print the content of help, when > > there is a single module for that software. With multiple modules the > > output is what we needed: > > > > > > > > ~]$ ml spider test1 > > > > > > > > ------------------------------- > > > > test1: > > > > ------------------------------- > > > > Description: > > > > whatis > > > > > > > > Versions: > > > > test1/1.0 > > > > test1/2.0 > > > > > > > > ------------------------------- > > > > For detailed information about a specific "test1" module (including > > how to load the modules) use the module's full name. > > > > For example: > > > > > > > > $ module spider test1/2.0 > > > > ------------------------------- > > > > > > > > > > > > To summarize: it is all good, I think we can get Lmod to do what we > > want. I just wasn’t aware of all these spider output details. > > > > > > > > Best, > > > > Damian > > > > > > > > > > > > *From: *Robert McLay <[email protected]> > > *Date: *Friday 30 June 2017 at 21:29 > > *To: *Kenneth Hoste <[email protected]> > > *Cc: *"Geimer, Markus" <[email protected]>, lmod-users > > <[email protected]> > > *Subject: *Re: [Lmod-users] Spider output - whatis vs help > > > > > > > > Either way is fine by me. Using the second style, you'd get: > > > > > > > > $ ml spider EasyBuild/3.2.0 > > > > > > > > EasyBuild/3.2.0: > > > > > > > > Description: > > > > ... > > > > > > > > Whatis: > > > > Homepage: http://hpcugent.github.com/easybuild/ > > > > > > > > R. > > > > > > > > > > > > > > > > On Fri, Jun 30, 2017 at 2:13 PM, Kenneth Hoste <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi Robert & co, > > > > Things are slightly different now (since EayBuild v3.2.0), thanks to > > changes made by Markus (in CC) [1]: > > > > help([[ > > > > Description > > =========== > > EasyBuild is a software build and installation framework > > written in Python that allows you to install software in a structured, > > repeatable and robust way. > > > > > > More information > > ================ > > - Homepage: http://hpcugent.github.com/easybuild/ > > ]]) > > > > whatis([[Description: EasyBuild is a software build and installation > > framework > > written in Python that allows you to install software in a structured, > > repeatable and robust way.]]) > > whatis([[Homepage: http://hpcugent.github.com/easybuild/]]) > > > > > > Markus: taken the below into account, do you think we should make > > any further changes? > > > > > > regards, > > > > Kenneth > > > > > > [1] https://github.com/hpcugent/easybuild-framework/pull/2113 > > > > > > > > On 30/06/2017 20:19, Robert McLay wrote: > > > > Here is a typical modulefile found at Univ. of Ghent that have > > been created by EasyBuild: > > > > > > > > whatis([[Description: ZeroMQ looks like an embeddable networking > > library but acts like a concurrency framework. > > > > It gives you sockets that carry atomic messages across various > > transports like in-process, > > > > inter-process, TCP, and multicast. You can connect sockets > > N-to-N with patterns like fanout, > > > > pub-sub, task distribution, and request-reply. It's fast enough > > to be the fabric for clustered > > > > products. Its asynchronous I/O model gives you scalable > > multicore applications, built as asynchronous > > > > message-processing tasks. It has a score of language APIs and > > runs on most operating systems. - Homepage: > > http://www.zeromq.org/] <http://www.zeromq.org/%5D>]) > > > > > > > > If you are using this format for your modulefiles, then you will > > see absolutely no change. My proposed change would add all the > > whatis calls that don't start with Description:. In this case > > there is only whatis() call in the modulefile and it starts with > > "Description:". This means that nothing new would be printed in > > the proposed "Whatis" section for a level2 spider output (namely > > ml spider boost/1.64) > > > > > > > > Please note that I don't expect that sites will change their > > modulefiles. Only that new information might be printed when > > doing "ml spider boost/1.64". > > > > > > > > The only other thing I'm saying is that Lmod does something > > special with a whatis call that starts with "Description" just > > like the one above. This means that site that don't generate a > > whatis("Description: ...") call in their modulefiles might > > consider adding it when they get a chance. > > > > > > > > I hope that this clarifies what I'm proposing. > > > > R. > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Check out the vibrant tech community on one of the world's most > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > > > _______________________________________________ > > > > Lmod-users mailing list > > > > [email protected] > > <mailto:[email protected]> > > > > https://lists.sourceforge.net/lists/listinfo/lmod-users > > > > > > > > > > > > > > > > -- > > > > Robert McLay, Ph.D. > > > > TACC > > > > Manager, HPC Software Tools > > > > (512) 232-8104 > > > > > > > > -- > 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 > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ >
