Neal,
"It's complicated". To a first appromimation, a dependency is a risk. As an illustration, I taught CRANberries a few years in its run to also consider disappearing packages. Right now, it knows about 3685 packages which are (or were at some point) "archived". This is an imprecise count as some are "reborn", while some are special and have multiple archive / readmitted / archive/ ... phases. But right now, we have 3685/13957 or 26.4% which are / were archived. Which is quite a lot. Hence "a risk". And just like other things in life you need to balance which risks are worth taking and which are not. Different people use different heuristics: - some trust certain packages more than others - some trust certain authors more than others - some trust certain communities more than others There are no hard or fast rules. Packages disappearing are a bit of pain, but "we all" buy into CRAN maintaining quality standard for ... actually enforcing them. But as it is somewhat related, I now show for some/most of packages what their count of dependecies is. Count is another very imperfect measure, but it provides a little bit on information at a glance. See [1] for more. As for the package at hand: maybe importing the functionality you need would work in the narrow sense. In the broader sense, adopting and maintaining the package would surely be best for the community as a whole. Dirk [1] http://dirk.eddelbuettel.com/blog/2019/03/14#020_dependency_badges -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
