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/
Related
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'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.
There's a semantic error in a function of an R package written by someone else. I contacted that person which is mentioned in the 'DESCRIPTION' file of the package over email, and there is no response. But, I need to move forward with my project.
Is it possible for me to correct that error and check-in the change of that project ? If that's not possible, should I write my own version of the function with the correction and call it? What would be the best way to move forward ? Thanks.
The only way to update that particular package on CRAN is to contact the package maintainer. But you can just obtain the package's sources (you can fork it from CRAN readonly mirror on a github), fix it your way and source changed .R files after loading the package (or build entire package from sources if your fixes are in C++ code). I've done it many times. If your changes may be useful to the community, you're encouraged to create your own package.
I have developed a R package, and I want to let anyone uses it by calling
install.packages(my package name)
help?
I tried to search on Google, and I installed some libraries to do that but these libraries make my package corrupted so i thought to ask you maybe you suggest me the best way
i would like if i have my package on github thanks
I think the best thing to do would be to go over to GitHub and do some reading. You mention in the comments that you want the user to be able to use install.packages() and not install_github(). For that you'll need to either submit your package to CRAN or make the tarball source available for download somewhere so that the user can install from source after download.
The CRAN Repository Policy is a good thing to read, as well as Writing R Extentions and of course all the info at GitHub.
By the way, devtools::install_github() is very widely used, so you may want to rethink your stance on only using install.packages() if not submitting to CRAN.
I have developed a R package, and I want to let anyone uses it
by calling
install.packages(my package name)
help?
That is precisely what drat is for. It lets you create a repository and by far
the easiest way is just to let GitHub host it. The package vignettes detail how.
See the drat documentation, or the blog posts about it. Also that we discussed just today in the r-packages-devel list how drat can help as an additional_repostitories even for CRAN packages.
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