Non tabular output denied for CSV conversion

[jyejare]

Problem Statement

The CLI command output containing non-tabular string is not eligible for CSV conversation.

e.g:

STDOUT like

stdout:
    Added Rpms: 32, Errata: 4
    Total steps: 84/84
    --------------------------------
    Associating Content: 39/39
    Downloading Artifacts: 0/0
    Downloading Metadata Files: 6/6
    Parsed Advisories: 4/4
    Parsed Comps: 3/3
    Parsed Packages: 32/32
    Skipping Packages: 0/0
    Un-Associating Content: 0/0

Here zipping in csv conversion function trying to zip the first row of 2 key_value pairs Added Rpms: 32, Errata: 4 with 1 row of key_value from next line Total steps: 84/84. Since strict is set to True the numbe of contents from first row and second row should match which does match with the tabular format but not the above-like output. Making the the strict zipping to fail.

Solution

Returning the output as is if the output is not sniffed using CSV Sniffer for CSV conversion eligibility.

Trying to make it simple though, we could also return all key-value pairs from such output but if the Team demands for it! Since its not returning all key value pairs for such output nobody complaints about it in the past so for now we should be good with the simple solution.

Related Issues

[jyejare]

trigger: test-robottelo

[jyejare]

trigger: test-robottelo

[lhellebr]

This broke csv parsing for (valid) csvs without delimiters, e.g.:

Message
Using configured credentials for user 'foobar'.

Because sniffer can't find a delimiter and thinks it's not a csv. But it is, it has one column called Message and one row with the actual message.

>>> import csv
>>> sniffer = csv.Sniffer()
>>> output = "Message\nUsing configured credentials for user 'foobar'.\n"
>>> sniffer.sniff(output)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.12/csv.py", line 194, in sniff
    raise Error("Could not determine delimiter")
_csv.Error: Could not determine delimiter

[lhellebr]

I see there are already some workarounds by @ogajduse and @pondrejk . I can add another for my case. Is it a good way though? Are we gonna add more and more exceptions? Opinions?

[jyejare]

@lhellebr For now please add the w/o similar to @pondrejk has added but we are looking for a better solution and have some options in hand.

@pondrejk do you have the results at hand from those options ?