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.
Related
Given an R package with a git repo on github, I'm looking for an optimal way to build a github hosted (gh-pages) site from the function documentation within the package (in the form roxygen2 comments). It'd be great to be able to include vignettes as well. Can anyone offer some pointers as to how to get started?
I've finally got around to trying pkgdown. It's still something of a work in progress, but very usable even at this stage. It does what I want.
I am trying to get my head around an R package. I installed it from github, worked with it. Also downloaded the ZIP-File from github which contains the files of the package. For experimental reasons I added some code in the files I downloaded.
Now I would like to see whether my changes do what they are supposed to do.
Is there an easy way to do this?
I would like to avoid creating a whole new package and installing it.
Or is this the only way?
I had the idea to directly change the code in the package I installed (location received from the function path.package()). Unfortunately I cannot access the code there.
The tutorials I read were also not helpful.
I would be thankful for any advice.
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
I've included a library called blotter in my R script which has a bug in it. Is there an easy way for me to edit the source to try and debug the issue?
Look up the trace and browser functions, they are the basic tools in R for debugging. Say you want to edit the source of function foo, then saying
trace("foo",edit=TRUE)
will open up the source of foo in the editor for you to change. However, this is for interactive debugging; the source files in the packages are not changed. So once you have found the bug, you need to change the package source files for the change to be permanent.
Such a feature is implemented in the development version of R (Jul 16, 2010):
A new facility has been added to r-devel for experimenting by authors of
packages.
The idea is to insert modified code from the package source into the
running package without re-installing. So one can change, test, change,
etc in a quick loop.
The mechanism is to evaluate some files of source code, returning an
environment object which is a snapshot of the code. From this
environment, functions and methods can be inserted into the environment
of the package in the current session. The insertion uses the trace()
mechanism, so the original code can be restored.
The one-step version is:
insertSource("mySourceFile.R", package = "myPackage", functions = "foo")
See this post for further details: Inserting and testing revised functions in a package
Your question of Is there an easy way for me to edit the source to try and debug the issue? has the obvious answer: Use the source, Luke!
blotter is a package on R-Forge from where you can get blotter sources here. That is the standard way of looking at Open Source and possibly helping it along with a bug fix.