[R-pkg-devel] [External] Re: What is a "retired"package?

[Avi Gross]

Philosophy aside, albeit not uninteresting, I am wondering about the
etiquette of developing a package and then years later dealing with how to
have it replaced carefully. Do creators and maintainers have any obligation
and especially when there is a large remaining embedded base of users. We
may have quite a few Y2K type problems in the sense that some people cannot
easily change what is being used. Other languages, like Python, have been
dealing with how the newer language features (version 3) have serious
incompatibilities with earlier versions and yet some stay with what they
have.

Hadley Wickham for example, has been involved in multiple packages including
cases like ggplot where it was replaced by another package with enough
incompatibilities that it might merit another name. I am not sure what
exactly was in plyr when it stopped being changed but in some ways the dplyr
package seems to focus on data.frames and plyr was more general. And, I
suspect, dplyr also tried to do things consistent with new design approaches
such as standardizing where arguments to a function go. It may well be
faster when used as planned.

But as a possibility, I suspect you could theoretically take the source code
for a package that has largely been replaced by others and sometimes make a
sort of compatibility version that consists largely of pointers to other
packages.

Specifically, the documentation could contain a section that suggests
alternatives to use. I suspect quite a few of the included functions may be
available in base R or another commonly used package (such as the tidyverse
collection) and just using the new one, perhaps with some alteration in how
it is called, might help guide existing users away to something more likely
to be maintained.

And sometimes, it might be weirdly possible to have a volunteer do something
a tad odd and set up a way to replace the functions in the package. A
function call like f(z, data) might simply be mapped into a call to
other::g(data, z, flag=FALSE) if that made sense. Other fairly small
wrappers might do more such re-direction. Obviously, this would be of
limited use if other packages would need to be loaded. I can imagine leaving
a package intact and adding a new function with a name like supercede() that
would make such a re-arrangement when asked to.

The user would normally call:

library(plyr)
plyr::supercede()

Without that additional line, nothing changes. But after calling it, you may
now be in a partial compatibility mode.

I now retire without being superseded.

-----Original Message-----
From: R-package-devel <r-package-devel-bounces using r-project.org> On Behalf Of
Martin Maechler
Sent: Wednesday, September 22, 2021 3:39 AM
To: Lenth, Russell V <russell-lenth using uiowa.edu>
Cc: r-package-devel using r-project.org
Subject: Re: [R-pkg-devel] [External] Re: What is a "retired"package?

>>>>> Lenth, Russell V 
>>>>>     on Tue, 21 Sep 2021 18:43:07 +0000 writes:

    > As I suspected, and a good point. But please note that the term
"retired" causes angst, and it may be good to change that to "superceded" or
something else.

well,  some of us will  become "retired" somewhere in the future rather than
"superseded" .. ;-)

______________________________________________
R-package-devel using r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel