I've been working with R for a long time, but I'm a complete newbie in writing (and/or publishing) own packages via CRAN. Actually, I create a new package for educational purposes (university) and I want to load it to CRAN, so my students (and, of course, others) can download and use it.
After I uploaded my package (let's call it “JohnnyStat”), is it possible that another person (let's call “Mark Miller”) modifies it and adds his name as another “co-author” (“author”/“contributor” etc.)?
So, as a result, the package “JohnnyStat” would be registered as written by “Johnny” AND “Mark Miller”?
No. Only the maintainer can upload package updates, not any co-author. An acceptance mail is automatically sent to the mail address of the maintainer. And no-one can become maintainer without the explicit consent of the previous maintainer (for obvious reasons).
If you want the possibility of various people modifying the package, maybe CRAN is not the best option. It is possible to install from other repositories. Why not have the package at e.g. R-forge or github?
You may get a more complete answer if you ask this on the CRAN mailing list R-package-devel.
Related
I've created an R package and I'd like to upload it to CRAN via GitHub Actions whenever I merge changes into the master branch. I've found a lot of examples of R actions and I've even looked up how some of the most popular packages like dplyr do it and even though I've found a devtools::release() helper function, I still haven't seen a workflow that would submit a library to CRAN when you merge changes into the master branch. Do package developers do this manually? Is there any reason why this hasn't been automated?
CRAN works quite differently from other language repositories, as uploads are not fully automated like in e.g. PyPI.
When you upload a new package, it is subject to verification from an actual human. When you update a package, if it triggers certain checks it will also be subject to a new review from a human. When a package uploads successfully and passes the first verification, many automated checks are run for it over the course of weeks (e.g. different OSes, compilers, compiler options, architectures, sanitizers, valgrind, etc.), and precompiled binaries are automatically generated for some platforms and R versions from your source code.
The CRAN policies explicitly state that frequent updates are not allowed, and you're not supposed to be submitting uploads any faster than once every couple months, for which I think this level of automation would not be worth it.
Even if you do want to automate this process, there is an email verification in the middle, so you'd perhaps have to do something with selenium + other scripts.
BTW if you are worried about complicated building processes and are using RStudio, you can configure on a per-project basis what arguments to use when building source or binary distributions of your package.
I use R pretty often and I have noticed that while checking any package's documentation at RDocumentation.org, some pages have errata so I'd like to help fix them if possible. I can't find any way to contact the website team. Any ideas?
I believe RDocumentation.org scrapes its information directly from CRAN/GitHub sources of packages, so it makes more sense to try to contact the package maintainers upstream.
Contributed packages
if a package is on GitHub, you can
fork the repository, fix the documentation errors yourself, and submit a pull request
record a GitHub issue (if there is an open issues list)
you might want to check to see if there is a README about contributions to see what the maintainers prefer
if the package is on CRAN, you can go to its CRAN page (e.g. here) and see if there is a development URL or BugReports: field in the description
if all else fails, the maintainer's e-mail is always available via maintainer("pkg_name")
Base packages
If you find documentation errors in packages that are maintained by R-core (unlikely but possible), you should probably start a discussion on the r-devel#r-project.org mailing list. Alternately, you can request write access to the R bug tracker (see here).
I'm building an Rmarkdown document reliant on a frequently updated data package that's hosted on github.
How do I make sure that the document is always built using the latest version of the package, without installing the package on each build?
You can see the list of commits to a package by getting the commits page for the package. For example,
https://github.com/tidyverse/dplyr/commits
shows that there were commits today. If you save a copy of the top hash in that response (currently af75177), and then update whenever it changes, you should be sure to have the latest version.
However, this is likely a bad policy. The package is not necessarily in a working condition after a commit: perhaps the author is planning another one a minute later to finish some update. It's much safer to use update.packages() and only get the updates that are judged to be stable enough to be sent to and accepted on CRAN.
I'm not new to R but I'm new to finding errors in CRAN packages which I wish to correct. In my case, I like to upload packages under development on github; then if errors are found people can generate pull requests so they're fixed. Not not everyone chooses to go down this route though.
My question relates to the above - if I find a (substantial) error in a widely used CRAN package (which I need to import in my own package), and I have fixed the errors, what are the steps to take? In particular if
the CRAN package does not have a project page (github etc.) and
the author is not replying to e-mails
Currently my solution is to upload a copy of the 'corrected' package on my github page and instruct people to install that version before using my own. This is cumbersome and not an elegant solution. Are there better alternatives to this?
This the good and the bad of R ... sometimes package are forsaken!
Get the source code and create your own pacakge. If it is useful for you it will be useful for others!
there a lot of documentations on how to create packages:
http://www.r-bloggers.com/create-an-r-package-in-under-6-minutes/
This is a followup to a question I posted earlier. To summarize, I am writing an R Package called Slidify, which makes use of several external non-R based libraries. My earlier question was about how to manage dependencies.
Several solutions were proposed, of which the most attractive solution was to package the external libraries as a different R package, and make it a dependency for Slidify. This is the strategy followed by the package xlsx, which packages the java dependencies as a different package xlsxjars.
An alterative is for me to provide the external libraries as a download and package a install_libraries function within Slidify, which would automatically fetch the required files and download it into the package directory. I can also add an update_libraries function which would update if things change.
My question is, are there any specific advantages to doing the CRAN dance for external libraries which are not R based. Am I missing something here?
As discussed in the comment-thread, for a package like slidify with a number of large, (mostly) fixed, and portable files, a "resource" package makes more sense:
you will know the path where it installed (as the package itself will tell you)
users can't accidentally put it somewhere else
you get CRAN tests
you get CRAN distribution, mirrors, ...
users already know install.packages() etc
the more nimble development of your package using these fixed parts is not held back by the large support files