Skip to content

[R-pkg-devel] What to do when a dependency falls off CRAN

4 messages · Neal Fultz, Dirk Eddelbuettel, David Winsemius +1 more

Original
Neal Fultz
# 
One of my clients has a shiny app which depends on RTextTools, which was
dropped from CRAN for lack of maintenance.

What would you all recommend in this situation? Here's a couple options I
could think of:

1) Vendor the orphaned package - we are doing this for now. I'm not a fan
of this, because then there's a mix of GPL-2, GPL-3, Apache 2.0 and
proprietary code all in one repo, and because it might encourage other
developers to write monolithic, non-modular code. At least when we find
bugs  we can fix them.

2) Install from CRAN archive instead of CRAN -  good for not having to
carry around third party code in our repo, but I'd expect this to break
with R 3.6, as the package hasn't rolled forward? Also no good way to fix
bugs.

3) Adopt package, push fixed one to CRAN - not sure what the exact process
is for un-orphaning, or if I would want to commit to maintaining it without
knowing more about why it was dropped and how much work it is to get it
passing. Eg if it were pathological solaris memory errors, I might have to
pass. Are there ways to see old automated CRAN checks on a package that was
abandoned? This approach obviously would benefit the community, but this is
probably not billable work.

4) Rewrite - I could do this, but it's probably tedious, weeks of work, and
my client may not want to pay for it; they also may not be interested in
sharing it back if they did.

5) Find another package - then I have to rewrite the "application" code
instead of the "library" code - also sounds tedious, days instead of weeks,
but more likely to be billable.

This topic has come up a few times in the past, but I would like to hear
your current opinions given that CRAN is much more rigorous and automated
now.

v/r

Neal Fultz
Dirk Eddelbuettel
# 
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
David Winsemius
# 
When I attempt to install it the error indicates that the maxent package 
is not available. Attempts to install that package fail with more errors 
than can fit on an Rstudio console, so I cannot even scroll to see the 
first error.

You could simply remove the dependency on that package if your 
application doesn't require the maxent algorithm. Most of the RTextTools 
package is R code.
Ralf Stubner
#
On 24.03.19 21:00, Neal Fultz wrote:
How about asking your client if they are willing to (partially) fund
somebody (does not have to be you) for getting the package back on CRAN?
They could be added to the DESCRIPTION in turn. And it might be cheaper
for them than rewriting the library or the application.

As for process: I think you basically upload a new version with higher
version number and updated "Maintainer" field. I have done this once for
tikzDevice, but that was only orphaned and not archived.

As for assessing the risks: Often the old checks are available for some
time after archiving, but I cannot find them in this case. Running "R
CMD check" on the two latest tarballs reveals only some NOTEs, though,
the most serious one from my point of view is usage of 'rand()' via
'random_shuffle()'
https://github.com/cran/maxent/blob/master/src/sgd.cpp#L77.

Greetings
Ralf