Graphs in builtin_types.ipynb are sometimes excessively scaled
Closed this issue · 1 comments
In builtin_types.ipynb, the two graphs are huge--that is, with far greater scaling than they should be and otherwise are--under some circumstances.
Specifically, this happens on GNU/Linux systems (I've tested on a couple Ubuntu systems and on Debian 11) when pipenv is used for installation. It doesn't seem to happen when conda is used for installation. I don't know if there are other situations where this occurs.
The problem strongly appears to be with Graphviz itself, since conda installs Graphviz itself but pipenv doesn't, defaulting to the system or manually installed version. In a recent test on Ubuntu 23.04 (development version) using pipenv, redrawing the graph makes this, among other changes:
- "<!-- Generated by graphviz version 7.1.0 (20230121.1956)\n",
+ "<!-- Generated by graphviz version 2.43.0 (0)\n",This may not really be related to operating system, per se, except that some operating systems' package managers provide Graphviz but at much earlier than the latest version. This is possibly related to Graphviz issue 1605, or to Graphviz issue 1855 which was fixed in Graphviz 3.0.0.
Manually building the latest stable version of Graphviz from source and installing it so dot appears in an earlier-listed $PATH directory works around the problem. (One place I've tested this is in the dev container.)
Screenshot in VS Code:
Screenshot in JupyterLab:
Notice the scaling of the graph drawing (including the text labels) compared to the text shown in the notebook.
This doesn't seem to ever happen on Windows, nor does it seem to happen on any system when conda rather than pipenv is used to install the dependencies.
Once a recommendation to use Graphviz 3.0.0 or higher is documented, I'm closing this based on the idea that it is due to a bug in Graphviz.
Quoting from #2:
The dev container works around #5, but it won't be reasonable to close until, at minimum, the issue is documented in the readme.
If this analysis is shown to be wrong or misleading, or if someone believes a better workaround is worthwhile, then this issue can be reopened, or a new issue can be created. (Anyone who considers the current behavior, including the note in the documentation, to be in need of improvement should feel free to open a new issue about it.)