Skip to content

[R-pkg-devel] how to notify users of obsolete and new package

5 messages · Bernd.Gruber, Kevin Coombes, Rolf Turner +2 more

Original
Bernd.Gruber
# 
Hi,

I have a quick question. I have an older package (dartR) that is now superseded by a series of new packages.

Still we noticed that several users have not updated yet and moved to the new package. Hence the question:

Is it okay to submit a "shell" package under the name of the old package that does nothing else than telling the user to install the new package (and a link/code how to do that)?

There would only be one function which is updating some legacy data to a new format.

Is that accepted or is there another way to let user know (e.g. via the CRAN package pages)?

Thanks and regards, Bernd


==============================================================================
Dr Bernd Gruber       Tel: (02) 6206 3804 Fax: (02) 6201 2328
Professor
Institute for Applied Ecology
Faculty of Applied Science
University of Canberra   ACT 2601 AUSTRALIA
Email: bernd.gruber at canberra.edu.au<mailto:bernd.gruber at canberra.edu.au>
WWW: http://www.canberra.edu.au/faculties/science/staff/profiles/dr-bernd-gruber

Australian Government Higher Education Provider Number CRICOS:#00212K

NOTICE & DISCLAIMER: This email and any files transmitted with it may contain
confidential or copyright material and are for the attention of the addressee
only. If you have received this email in error please notify us by email
reply and delete it from your system. The University of Canberra accepts
no liability for any damage caused by any virus transmitted by this email.

==============================================================================

[UC Logo]<http://www.canberra.edu.au>

[Adobe Creative Campus. Fuel your ceativity, Adobe Express free for all UC Students and Staff.]<https://www.canberra.edu.au/on-campus/adobe-creative-campus/>



The Ngunnawal people are the Traditional Custodians of the ACT where UC's Bruce Campus is situated and are an integral and celebrated part of UC's culture. We also acknowledge other First Nations Peoples.

Australian Government Higher Education Registered Provider (CRICOS) #00212K. TEQSA Provider ID: PRV12003 (Australian University)
Email Disclaimer<https://www.canberra.edu.au/about-uc/disclaimer-copyright-privacy-accessibility>

[UC Facebook]<https://www.facebook.com/UniversityOfCanberra>  [UC Instagram] <https://www.instagram.com/unicanberra/>     [UC Linkedin] <https://au.linkedin.com/school/university-of-canberra/>     [UC Youtube] <https://www.youtube.com/user/uniofcanberra>  [University of Canberra] <http://www.canberra.edu.au>
Kevin Coombes
# 
Does the old package give incorrect results? Or does it just give slower
results? What makes the new one better?

Unless the old one is actually wrong, as a user, I would be unhappy with it
being replaced by a shell. I have this obsession with reproducibility. So,
if you force me to change to the new package, I have to go through a lot of
work and perform many tests to make sure my old calculations are still
correct in the new context. And I have to hunt down every place I used the
package to make the changes.

Why not just create a package startup message for the old package that
tells users why you think your new package is better? It should then be up
to them to decide if and when they make a change.

But what do I know? I still use emacs as my default editor. It took me
decades to switch from plain TeX to LaTeX. I still manage photos with an
archived version of Google's Picasa, since I don't have any reason to store
all my personal photos in the cloud (but I do use an automated cloud
backup). And I still use a music composition program that was written for
Windows 95, by running it in a Windows XP virtual machine on my Windows 11
laptop. And I get (mildly) annoyed every time R Core makes a change that
causes the test scripts in one of the R packages I maintain to give
different answers than they have been giving for years.

Best,
   Kevin

On Mon, Feb 10, 2025, 4:55?PM Bernd.Gruber <Bernd.Gruber at canberra.edu.au>
wrote:

  
  


  


      

    

    

      
      

        


  

        

      Rolf Turner
    

    

      
      #
    

  


  

      
On Mon, 10 Feb 2025 21:55:07 +0000

        
Bernd.Gruber <Bernd.Gruber at canberra.edu.au> wrote:

        

            

      
      
      
    

        
I am sympathetic to the points made by Kevin Coombes, who has also
replied to you.  OTOH I am obsessive about redundancy and clutter.  So
I dunno.

Some while back I put a package "hse" (standing for "hope springs
eternal" ??) up on CRAN.  Then later I wrote a paper about the ideas
implemented in hse.  A referee objected to the name, so I changed the
name to "dbd" ("discretised beta distribution").  But I left a skeleton
of hse on CRAN.  It just consists of the .onAttach() function.  If you
install and load hse you just get the message:

     This package, "hse" is now deprecated.   Users 
     should install and use its successor "dbd".

So far no-one has yelled at me ....  But maybe no-one ever used hse.

cheers,

Rolf Turner

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Greg Hunt
    

    

      
      #
    

  


  

      
If as your install page says, there are only trivial differences in the
code that uses the old and new packages, why force people to reinstall by
disabling their code with what you term a shell?  Surely a package startup
message would be enough, and better than disabling your users' previously
(hopefully) working code.  Having a package suddenly stop working is fairly
annoying and happens all the time through the usual entropy in complex open
source systems, having that failure created deliberately is just adding to
the annoyance and is likely to impose time costs on users at moments that
they did not choose.   I have had this happen a number of times:  some
small project that I've left for a few weeks and returned to expecting to
take a few minutes to do some trivial update and re-generate a graph or a
notebook and discovered that due to a rash update of some kind (R, Python
or OS packages) that I have to spend time I don't have bringing the pieces
up to date.  Big, long-lived things, sure, they get their environment
frozen, but the transient or ad-hoc pieces of work eat time with this type
of problem.  If it can be avoided, it should be.

The dartR GitHub page (https://green-striped-gecko.github.io/dartR/) and at
https://github.com/green-striped-gecko/dartR/ does not mention that the
package has been superseded, you have to read the install page, which is
surprising given this email thread.  One additional way of letting people
know about the new version would be to put it on the github page and in the
readme.

It looks like the dartR package has been removed from CRAN due to
uncorrected errors in the code.

Greg

On Tue, 11 Feb 2025 at 08:55, Bernd.Gruber <Bernd.Gruber at canberra.edu.au>
wrote:

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    
2 days later

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
On 11.02.2025 10:40, Rolf Turner wrote:

            

      
      
      
    

        
You can do that and then let that package be archived after a while.

            

      
      
      
    

        
Yes, we can archive a package and report on the web page of the package 
that it has been superseded.
Some example:
<https://cran.r-project.org/package=eodhd>


Note that CRAN does not like the idea of retiring a package and 
replacing it by another one. This should only be a very exceptional 
action and CRAN will decide case based.
Ideally a new version of the old package should do.

Best,
Uwe Ligges