Idea: "Non-fixed" dependencies
Closed this issue · 7 comments
I was looking at plots with Suggests on when all hell breaks loose once more levels are added. Consider data.table which, after all, has zero strong dependencies:
I would love to the the hard costs of the weak suggests: Use Suggests for the first level, but after that fall back to "strong" (or some other measure). This would allow a visualization of the full ("strong") costs of weak links in Suggests:.
Yes / No / Maybe ?
So, what you mean is that there would be possibility of separately setting types for the root package and for all others? I believe this is within realms of possibility, though I'm yet to assess, how much. As an additional argument to plot_dependencies(), reasonably doable; as an extension of dependency_type argument od deepdep(), a bit harder. And - yes, it would declutter the visualization quite a bit.
However, if you meant that Suggested packages should have less types of dependencies than Imports and Depends, it looks a bit too complicated, not even to code, but to interpret.
Yes -- I had the same follow-up thought that to a first degree maybe want this just as an option for plotting to 'lighten' the plot. The returned data object could (should) still have it.
I've written a code that declutters the plot (controlled by a boolean declutter argument) and it makes a difference for data.table. I'm still thinking about the best approach there: whether declutter should be able to take a character vector of dependency types to keep/omit, whether the process should be more intelligent, turning off dependencies and hiding less important (what does it mean?) labels when there are too many of them.
Or maybe don't overcomplicate it? After all, if a user wants to plot a very specific subset of data, they can run deepdep() first and then filter the data before plotting it. If so, then declutter might not be the most descriptive name, though I guess it would work.
That is awesome. And a boolean added to only the plotter is a very good, non-invasive solution.
This answers the question: what do we need the Suggests of a given package to be installed with that package, and it could be called the effective "weight" or "effect" of Suggests.
Great, I'll cover the code with tests then and prepare for next release.
Thanks for implementing the idea, and the subsequent bugfix. Truly appreciate it. I just put it to use on Twitter but only realized after the tweet that I should have posted the code as an alt text :-/ Sorry. Will beat the drum some more another time.
The posted image conveys what I had in mind really well. We think of a package and its Suggests: but the cost of those Suggests: is the decluttered graph, not the full graph:
Wow, great! Also, I see you encountered a bug with misaligned circle when there's only one dependency. But that's a separate issue for 2022...