Error log usability

[ottokruse-sd]

The error log is hard to use at the moment. The following improvements would increase its usability:

1. Note whether particular line is WARNING or ERROR at start of line
2. Identifying information in each statement that links back to input or output of tool (BOM reference number or line number), as it stands you have to text search in the csv file to find things
3. Identifying text at the start of the log file (when it was run, what was run perhaps by echoing command line, then a blank line before error log statements
4. Print number of Warnings and Errors into log file

[pombredanne]

@ottokruse-sd agreed, the error logging is not great and we need to beef it up.
What we have today are many confusing ways to handle this:

In the master branch and v2.x release stream.

1. with about.py, we have errors/warning on the same row as an about entry in two cells on the far right: warnings and errors columns. This is for the master branch and v2.x release stream.
2. with genabout.py, we have errors/warning logged in an error.log file

In develop, there is yet another an experimental approach which has not been firmed up

I think these approaches could be improved this way:
For about.py proper:

• always create a completely separate error log file, and not store anything in the collected inventory CSV

Pros: this allows more refined error info

Cons: this separates the data with errors from the corresponding error messages

• keep the error/warning messages in-line with the collected CSV inventory but store it differently:
  • if there is an error or warning, create a new row in the CSV listing the error message in the same column that has an error/warning. Ensure that this row has a few essential fields such that the CSV sorts correctly and may be a "row type" column to distinguish data rows from warning/errors message rows.
  • if there is no error/warning for a row, do not create such "information" additional row
  • we could use a also a top level/global information row to store housekeeping information such as time of the run, version in use, command line arguments

Pros: data and validation errors and warning are side-by-side. The validation message is located side-by-side with the invalid value, so no search is needed: errors can be fixed in place right away. The info rows can be easily filtered out of the output (and ignored when using such a CSV file as an input).

Cons: none that I can think of.

For the the generation of ABOUT files and the attribution generation, we could also use the same approach: instead of providing a bare log file, we could provide a more structured output in a CSV, such that you have the validation messages side-by-side with the data that has a validation problem. Since this CSV output could have the same columns as an About inventory, it could become much easier to fix the errors there and possibly regenerate your ABOUT files and rerun attribution from that basis.

So you would use a CSV and ABOUT files as an input and get an output which contains the original data and possible validation messages side by side on a different row.

To fix errors, you open the CSV, edit and save it, then rerun your command again using this corrected CSV as an input. You can iterate on this without needing to go back an forth between the data and validation errors.

This could be an approach. What is your take?