Very excited to see some of the recent (and continued) performance improvements being made to this excellent package.
To my question...
Is their any appetite for reducing the size of did's dependency tree?
As things stand, the package currently imports over 70 recursive dependencies. The biggest culprit here appears to be ggpubr, which pulls in nearly 60(!) recursive dependencies all on its own. This seems particularly excessive given that you only call two minor functions from this latter package, which could be pretty easily mimicked by native ggplot2 functions:
In general, I think it's good practice to reduce non-essential package dependencies where possible. But FWIW I was motivated to look into this after finding that did was adding non-trivial build times to a Docker container that I'm building for a project.
PS. I'm contractually obliged to point out that ggplot2 itself requires over 20 recursive deps. If you're in the market for a 0-dep alternative, then I can always look into a tinyplot PR ;-)
Hi folks,
Very excited to see some of the recent (and continued) performance improvements being made to this excellent package.
To my question...
Is their any appetite for reducing the size of
did
's dependency tree?As things stand, the package currently imports over 70 recursive dependencies. The biggest culprit here appears to be
ggpubr
, which pulls in nearly 60(!) recursive dependencies all on its own. This seems particularly excessive given that you only call two minor functions from this latter package, which could be pretty easily mimicked by nativeggplot2
functions:ggpubr::theme_pubr
<->ggplot2::theme_classic
ggpubr::rremove("legend")
<->ggplot2::theme(legend.position = "none")
In general, I think it's good practice to reduce non-essential package dependencies where possible. But FWIW I was motivated to look into this after finding that
did
was adding non-trivial build times to a Docker container that I'm building for a project.Cheers, Grant