[bug] Unconnected components are ignored by v0.4-dev

[kvid]

The current dev branch (after merging in multiple PRs this summer) is no longer able to document unconnected connectors or cables - as has been possible with all releases (at least v0.2 and later).

This is a minimal example to document a single connector without any connections:

connectors:
  X1:
    pinlabels: [GND, VCC]

With the current dev branch, this results in an empty diagram - which is not very useful!

Why is the algorithm that generates the diagram rewritten to only add components that are referred to from connections? That makes it impossible to document e.g. a loop-back connector, which is not an unusual use case. See also the slightly related #217.

The PR #251 on top of dev does not seem to help with this issue.

[kvid]

If this new fuctionality is intended as a feature, then it might be a solution to #294. However, in that case, it should not be the default option, IMHO, because I find it counterintuitive unless deliberately activating it as an optional feature, e.g. by setting: options.hide_unconnected_nodes=true

[17o2]

Thanks for bringing this up.

The easy fix with the current code, is to define a connection set, with only that connector included:

connectors:
  X1:
    pinlabels: [GND, VCC]

connections:
  - - X1

The question is where harness.add_connector() is called, which currently only happens inside for connection_set in connection_sets: after resolving designators etc., instead of during initial YAML parsing.

~~I am OK with restoring the old behavior, feel free to submit a PR and adding the option as you suggest. Bear in mind the same would apply to unconnected cables as well. In the end, it is a matter of preference.~~ [Edit: see comment below] The alternative is to add the above fix (with a one-line connection set) to the documentation, which I would be fine with as well, since adding more and more options makes using the tool more unwieldy, IMHO.

[sb424dat]

I you want I can add this to the documentation and try some test cases on my machine!

[17o2]

I am coming back to this issue, and I can now offer a better explanation. TL;DR: it's a feature, not a bug; but I agree it was an unexpected side effect of that feature.

Previously, connectors were immediately generated unless they were explicitly meant for autogeneration, then added to the harness, and thus rendered. Cables did not have autogeneration capabilities.

https://github.com/wireviz/WireViz/blob/b0d0070f08247e132b11bf45e617da9e8e1881f1/src/wireviz/wireviz.py#L64-L68

However, after implementing the new autogeneration syntax proposed in https://github.com/wireviz/WireViz/issues/184#issuecomment-714490695, implemented in https://github.com/wireviz/WireViz/pull/186 and explained in the new syntax description* , the autogenerate property is no longer used, and the decision whether a connector (or cable!) should be instantiated as "itself" or as a new autogenerated instance, is only made by resolving the designators called in the connection set

https://github.com/wireviz/WireViz/blob/9cb9ede487c94fec6013bed11f7017be783773d2/src/wireviz/wireviz.py#L240-L254

and only afterwards is the harness actually populated populating with them.

https://github.com/wireviz/WireViz/blob/9cb9ede487c94fec6013bed11f7017be783773d2/src/wireviz/wireviz.py#L279-L286

Since I strongly believe the new autogeneration syntax is more robust and flexible**, I will preserve the current behavior and instead amend the syntax description with a note on how to force rendering components that are not connected by referencing them in a one-line connection set as described above.

connections:
  - - X1

---

* There are still some mentions of the autogenerate: true attribute in the dev branch's syntax description. I will reword these as well.

** For example, the new syntax allows to generate multiple complex but identical components by using autogeneration, without resorting to YAML templates, and while still allowing the user to assign designators for every instance.

connectors:
  X_template:
    # ... complex connector description

connections:
  -
    - X_template.X1: [...]
    - ...
    - X_template.X2: [...]
  -
    - X_template.X3: [...]
    ...

[kvid]

@formatc1702 - thank you for the detailed explanation above. I now agree that the advantages with the new algorithm are probably greater than the disadvantage about breaking the old way to document an unconnected connector. The disadvantage can be reduced by describing such use cases in the documentation and maybe include a proper example. How can we best give the user an explanation about the reason when generating an empty diagram? There might also be other possible reasons for this than the use case described in this issue.

[17o2]

See the updated syntax description in the unreleased interim v0.4 for a (IMHO) concise and simple explanation and solution.