[feature] Only output the files that user requests

[formatc1702]

Currently, running WireViz generates multiple output files from the YAML input by default:

• .png raster image
• .svg vector image
• .gv GraphViz code
• .tsv BOM
• .html page with embedded diagram and BOM (feature to be expanded, see # 32)

Especially the GraphViz code is probably not of much interest to the end user. The output() function in Harness.py should be updated to only actually generate the files the user needs.

A good default behavior should be set, ideally just with one file type to avoid cluttering the file system.

[aakatz3]

I had looked into this before, and there are a couple of different ways this can be done, from refactoring the outputs to simple if-else statements. The Graphviz DOT file can be useful as it can be converted into something like a Visio document, but (and I have to check the code,) I think its generated due to how Graphviz processes the DOT file to generate conversions. Since it externally calls the dot executable, and the dot executable needs to read from disk (at least by default), I think we would have to just delete the file if the user does not request it, unless Graphviz and the python library for it support sending the info via named pipes.

[formatc1702]

Right now the .gv file is explicitly saved so that's easy to fix.

I'd say a couple of if statements, the possibility to specify what to output when running from command line: $ python wireviz.py inputfile.yml -png -csv -html or similar and setting good default behavior (my vote: generate PNG only so as not to generate clutter).

[slightlynybbled]

If you are looking for a great library, check out click. Pure python and easy to maintain. No chained if statements. Have successfully used this on several internal CLI packages.

[formatc1702]

That looks quite interesting.

@slightlynybbled would you be interested in taking over this issue and rewriting the current CLI handling?

Currently, the --generate-bom an --output-file flags are unused and could be simplified as proposed below.

The usecases I envision: wireviz inputfile.yml <- default behavior: output only PNG wireviz inputfile.yml --prepend library.yml <- to include e.g. a library of templates/parts to reference in the inputfile * wireviz inputfile.yml --output png svg gv csv tsv html pdf <- accept one or more options for output and generate the respective files. Some options (csv, pdf) are not yet implemented and could be filled with placeholders wireviz --help <- is this augo-generated by click?

*[Note] prepending a file is already implemented, though poorly tested (by me, at least). It is a really useful option since YAML does not support including files by default. The idea is that one could curate a library of commonly used connectors and cables:

# this is library.yml
molex_kk254_female_4pin_from_library:
  type: KK 254
  subtype: female
  pincount: 4
  pn: xxx
  mpn: yyy
  manufacturer: Molex

and then include them in inputfile.yml like so:

# this is inputfile.yml
connectors:
  X1:
    <<: *molex_kk254_female_4pin_from_library # this will work since the --prepend'ed file will be appended before it goes through WireViz's YAML parser
    pinlabels: [GND, VCC, SCL, SDA]
    notes: Just edit any attributes that are not specified in the library, or need overriding

[kvid]

Currently, running WireViz generates multiple output files from the YAML input by default:

• .png raster image
• .svg vector image
• .gv GraphViz code
• .tsv BOM
• .html page with embedded diagram and BOM (feature to be expanded, see #32)

.csv becomes a new BOM output format when #116 is merged in - probably quite soon, as it seems from the last comment https://github.com/formatc1702/WireViz/pull/116#issuecomment-662245083.

A good default behavior should be set, ideally just with one file type to avoid cluttering the file system.

I suggest an --all option to output every possible format when the default becomes less than all formats.

[aakatz3]

It would also be great if the YAML had the ability to specify the requested outputs.

[kvid]

It would also be great if the YAML had the ability to specify the requested outputs.

I agree, but I would like to be able to override such YAML specifiers with the CLI, and in that case we would need to define how to handle conflicts: Should any CLI specifier presence make all YAML specifiers to be ignored, or should it happen specifier by specifier instead? In the latter case, negative specifiers (e.g. removing 'csv' if that was specified by the YAML specifiers) might be needed.