🐕🌭 Show some data-driven, reusable software documentation examples

[nrbgt]

This project is (or will soon be) complex enough to show non-trivial demos of:

• source code navigation
  • show a nested file treemap (sized by SLOC, etc.), click to view syntax-highlighted source
• architecture diagrams
  • see how we're subclassing Widget, Box, etc.
• automation processes
  • look at the doit graph
• dependencies
  • see the fully resolved pip/conda relationships represented in lock files, etc.
• profile information
  • call graph
• widget linkages
• test logs
  • show robot screenshots in plots

These would be cute to test, as we could take the generated SVG artifacts and put them in (eventual) documentation, but these seem like useful tools, especially for canonical outputs of common developer tools.

[dfreeman06]

How does one grab the conda sat solver input constraints, i.e. resolve all of the numpy >=1.14,<1.19 through out the chain or maybe just the output of when conda can't solve for an environment?

I am thinking of the packages as nodes and the different ports being the version constraints. We might be able to have ports on the WEST being constraints and ports on the EAST being package releases.

This still might be too large or a diagram / number of edges to be useful but if we can show the conflicts that might be small enough to be meaningful.

[nrbgt]

Yeah, the SAT jumps up to 10k+ clauses really fast, and then manipulates them over a few passes. I think more like some of the mamba features, but not sure if they have a JSON data export, or just the ASCII art...