How to rename an R package

I have written a package that I do not wish to change, but I now wish to write a slight variant of it. When that variant is working and if I like it, I may wish to merge it with the older package, but for now I just want to get the variant working to see if it is something I want to proceed with.

What I want to do is this:

  1. My existing package is package0.
  2. Copy package0 to new folder, so I now have two identical packages named package0 saved in different folders
  3. Rename the second as package1
  4. Amend package1

My problem is that renaming a package seems to require lots of individual text amendments in a variety of files.

Is there an easy way to rename a copy of a package?

Not answering directly...


Very many thanks for such a quick response. The blog post is very helpful, but it does confirm my original thought that name changing is not all that simple.

1 Like

Isn't enough to change the name in the DESCRIPTION file and rebuilt it?

Sadly not: see the documentation of the package changer .

Hi @jeremycolman, @maelle has a very good point there, but I am quite curious why what I said actually works....

See a minimal example:

First I just downloaded a tarball of a package (in this instance geosed) from CRAN, and unzip it a test-name folder in my Desktop folder....

This is how it looks at start the folder

fer@lemmus:~/Desktop/test-name$ ls -l
total 4
drwxr-xr-x 4 fer fer 4096 Nov  3 18:35 geosed

Now I build it using standard routines

fer@lemmus:~/Desktop/test-name$ R CMD build geosed
* checking for file ‘geosed/DESCRIPTION’ ... OK
* preparing ‘geosed’:
* checking DESCRIPTION meta-information ... OK
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* building ‘geosed_0.1.1.tar.gz’

Well, that's expected, it built geosed :slight_smile:

Now I simply change package name (see the screencapts of the minimal change of the first line of the DESCRIPTION file, from geosed to a more tasty blueAgedStilton):


geosed to blueAgedStilton


This is the ONLY change I've made, and now I will rebuild geosed:

fer@lemmus:~/Desktop/test-name$ R CMD build geosed
* checking for file ‘geosed/DESCRIPTION’ ... OK
* preparing ‘blueAgedStilton’:
* checking DESCRIPTION meta-information ... OK
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* building ‘blueAgedStilton_0.1.1.tar.gz’

please NOTE that still I am building the same folder with exactly the same code as below and the name geosed, but R CMD build is reading the package with its new tastier blueAgedStilton name.

and checking again the folder:

fer@lemmus:~/Desktop/test-name$ ls -l
total 20
-rw-r--r-- 1 fer fer 7219 Nov  3 18:37 blueAgedStilton_0.1.1.tar.gz
drwxr-xr-x 4 fer fer 4096 Nov  3 18:36 geosed
-rw-r--r-- 1 fer fer 7202 Nov  3 18:36 geosed_0.1.1.tar.gz

Both tarball coexist.

Then in R:

install.packages("~/Desktop/test-name/blueAgedStilton_0.1.1.tar.gz", repos = NULL, type = "source")
Installing package into ‘/home/fer/R/x86_64-pc-linux-gnu-library/3.6’
(as ‘lib’ is unspecified)
* installing *source* package ‘blueAgedStilton’ ...
** using staged installation
** R
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation path
* DONE (blueAgedStilton)

## check it it is actually installed...

> library(blueAgedStilton)
## no sign of error.

And one of the examples from the help files

> library(blueAgedStilton)
> sample_coord <-
+         matrix(
+              c(
+                  sample(327131680:419648450, 3) / 10000000,
+                  sample(-1147301410:-1241938690, 3) / 10000000
+              ),
+              ncol = 2
+          )
>      # Generate sed center and radius
>      gtc <- geo_trivial_circle(sample_coord)
> gtc
[1] 318.8123

[1]   37.18726 -117.97616

         [,1]      [,2]
[1,] 37.08444 -115.0803
[2,] 35.11864 -115.5170
[3,] 39.20222 -120.5720

Have a nice day!!

1 Like

Many thanks. Well! I am surprised.

I just know because often, for my packages, I just copy and paste some of the stuff of previous ones as starting point, and once one package just was built and installed/tested with the other package name, because I forgot to change the field Package: in the DESCRIPTION field.

Of course I completely discourage anyone one to do it with third party packages etc, as it would look as a way to "get credit from other's work, or diminish it", but as you are doing that with your own package, that seems a pretty easy way to do, as you already know documentation, functions... and as for your own use and development, it could be a much smoother pattern. You can work the same scripts and tests for the two different packages... jus changing ther first line of them: library("someLovedCheese")
You can actually do the same thing using git branches, but it requires to know how to use it


The article linked in @maelle's post above is a great start - especially the recommendation to search all files in the directory for the prior project name.

If you're using devtools, check() may help you catch some inconsistencies before you begin an exhaustive search, including the name of your .Rproject file, testing errors caused by testthat.R calling library(my_old_package_name), etc.

1 Like

This topic was automatically closed after 45 days. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.

Learning version control would not be simple either but it'd be useful many more times in the future. :innocent:


Yes, I can see that I'll try both and see which suits me best.

I had missed this: (not tested). Maybe there are others, I kinda remember seeing one on Twitter :thinking:

Many thanks Maelle. That is just what I was looking for.