[report] Fix html formatting for Plugin section

[jcastill]

After moving from .format() to f-strings via
57d2134, the formatting for Plugin sections was
lost. This patch attempts to fix this while still
using f-strings.

Related: #3780

---

Please place an 'X' inside each '[]' to confirm you adhere to our Contributor Guidelines

• Is the commit message split over multiple lines and hard-wrapped at 72 characters?
• Is the subject and message clear and concise?
• Does the subject start with [plugin_name] if submitting a plugin patch or a [section_name] if part of the core sosreport code?
• Does the commit contain a Signed-off-by: First Lastname [email protected]?
• Are any related Issues or existing PRs properly referenced via a Closes (Issue) or Resolved (PR) line?
• Are all passwords or private data gathered by this PR obfuscated?

[packit-as-a-service]

Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

• sudo yum install -y dnf-plugins-core on RHEL 8
• sudo dnf install -y dnf-plugins-core on Fedora
• dnf copr enable packit/sosreport-sos-3781
• And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

[TurboTurtle]

Two thoughts, no particular preference on either:

1. We are only using these in 2 places, we could simply do the f-string in-line instead of breaking it out into a function. We haven't really made any major changes to how the HTML reports are generated for in a very long time so I doubt we're going to be expanding the use of these any time soon.

2. If we keep it as a function, then we don't use camelCase in sos, and PEP8 explicitly discourages it

[jcastill]

Two thoughts, no particular preference on either:

1. We are only using these in 2 places, we could simply do the f-string in-line instead of breaking it out into a function.  We haven't really made any _major_ changes to how the HTML reports are generated for in a very long time so I doubt we're going to be expanding the use of these any time soon.

Fair enough. The problem I tried to solve was for example with PLUGLISTITEM, we have a definition for plain text and another one for html, and while setting the variable via f-strings was a bit tricky. Do you know if there's a pythonic way to use f-strings with strings defined as variables like PLUGLISTITEM?
Another option, perhaps, is to set a is_html boolean var, and if that's true, then add the html code, and if it's false (i.e. coming from the plain text report) then just print the var. Something like:

str_plugin = [ f"{value}" if not is_html else f'<td><a href="#{value}">{value}</a></td>\n' ]

2. If we keep it as a function, then we don't use camelCase in sos, and PEP8 [explicitly discourages it](https://peps.python.org/pep-0008/#function-and-variable-names)

Sorry, it seems that old habits die hard...

[jcastill]

Fair enough. The problem I tried to solve was for example with PLUGLISTITEM, we have a definition for plain text and another one for html, and while setting the variable via f-strings was a bit tricky. Do you know if there's a pythonic way to use f-strings with strings defined as variables like PLUGLISTITEM? Another option, perhaps, is to set a is_html boolean var, and if that's true, then add the html code, and if it's false (i.e. coming from the plain text report) then just print the var. Something like:

str_plugin = [ f"{value}" if not is_html else f'<td><a href="#{value}">{value}</a></td>\n' ]

Replying to myself: List comprehension won't be the best approach here, because we are concatenating the result. Perhaps an old fashioned if/then could be simpler.

[pmoravec]

As we use the %(name)s syntax else-where in reporting.py, what about patch:

--- a/sos/report/reporting.py
+++ b/sos/report/reporting.py
@@ -136,11 +136,11 @@ class PlainTextReport:
     ALERT = "  ! %s"
     NOTE = "  * %s"
     PLUGLISTHEADER = "Loaded Plugins:"
-    PLUGLISTITEM = "  {name}"
+    PLUGLISTITEM = "  %(name)s"
     PLUGLISTSEP = "\n"
     PLUGLISTMAXITEMS = 5
     PLUGLISTFOOTER = ""
-    PLUGINFORMAT = "{name}"
+    PLUGINFORMAT = "%(name)s"
     PLUGDIVIDER = "=" * 72
 
     subsections = (
@@ -168,7 +168,7 @@ class PlainTextReport:
         i = 0
         plugcount = len(self.report_data)
         for section_name, _ in self.report_data:
-            line += f"  {section_name}"
+            line += self.PLUGLISTITEM % {'name': section_name }
             i += 1
             if (i % self.PLUGLISTMAXITEMS == 0) and (i < plugcount):
                 line += self.PLUGLISTSEP
@@ -177,7 +177,7 @@ class PlainTextReport:
 
         for section_name, section_contents in self.report_data:
             line_buf.append(self.PLUGDIVIDER)
-            line_buf.append(f"{section_name}")
+            line_buf.append(self.PLUGINFORMAT % {'name' : section_name})
             for type_, format_, header, footer in self.subsections:
                 self.process_subsection(section_contents, type_.ADDS_TO,
                                         header, format_, footer)
@@ -224,11 +224,11 @@ class HTMLReport(PlainTextReport):
     ALERT = "<li>%s</li>"
     NOTE = "<li>%s</li>"
     PLUGLISTHEADER = "<h3>Loaded Plugins:</h3><table><tr>"
-    PLUGLISTITEM = '<td><a href="#{name}">{name}</a></td>\n'
+    PLUGLISTITEM = '<td><a href="#%(name)s">%(name)s</a></td>\n'
     PLUGLISTSEP = "</tr>\n<tr>"
     PLUGLISTMAXITEMS = 5
     PLUGLISTFOOTER = "</tr></table>"
-    PLUGINFORMAT = '<h2 id="{name}">Plugin <em>{name}</em></h2>'
+    PLUGINFORMAT = '<h2 id="%(name)s">Plugin <em>%(name)s</em></h2>'
     PLUGDIVIDER = "<hr/>\n"
 
     subsections = (

[jcastill]

@pmoravec I think this may work as well.
We have now a number of different possible solutions. Which one should I send?

[pmoravec]

No strong preference. Just the %s-strings are quite obsolete (citation needed) and we might rather use .format() syntax..?

[pmoravec]

Hi @jcastill , are you planning to update the PR..?

[jcastill]

@pmoravec will push a new PR with your suggestion asap.

[jcastill]

rpm build for Fedora 40 issue fixed by #4014

[pmoravec]

rpm build for Fedora 40 issue fixed by #4014

Could you please rebase your PR there?

[jcastill]

rpm build for Fedora 40 issue fixed by #4014

Could you please rebase your PR there?

Ack, will do it this morning

[pmoravec]

This removes leading spaces - isnt it a problem?

[jcastill]

I didn't see an issue when I checked the result, but I'll add the spaces to keep the same format

[pmoravec]

Why the current f-string cant be used? (ditto for self.PLUGLISTITEM)

[jcastill]

I used f-strings originally but then I used your approach as per #3781 (comment)