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.
Related
I'm writing an R package using devtools and roxygen2. Note that this is my first time making a package, so maybe I am missing something important.
I want to add a dependency, the package, DESeq2. I have tried to do this in a number of ways, but believe the right way is to add the following to my DESCRIPTIONS file.
Depends:
DESeq2
If I add this, when I build and reload I get a fatal error. When running in RStudio it just gives a "Fatal Error" dialog and restarts the application. It appears to build, but when it does, library(myPackage), it crashes immediately.
If I remove the Depends section from the DESCRIPTIONS file it builds and loads fine. What's more, if I include a different package, for example, ggplot2, then it builds and loads fine as well.
What about a package would cause it to fail to load as a dependency and completely crash? Is there another way to require it or is there any way to dig deeper into the cause?
Thanks very much in advance.
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.
This a follow-up to How to edit and debug R library sources. I'm wondering if there's an easy way to edit an R library source file and cause the edited file to be loaded by library without reinstalling the code. I'm asking this in the context of a library that I'm developing and am looking for an easy way to incrementally edit and test my code. I know about source and other ways of loading code into an R session, but I want to test scripts that do the usual library thing.
Thanks!
It sounds like you're developing a packages. If that's the case then using the devtools package is probably what you want to do. The load_all() function will systematically reload all of your code so you can make changes and test everything out.
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.
In order to be able to compare two versions of a package, I need to able to choose which version of the package that I load. R's package system is set to by default to overwrite existing packages, so that you always have the latest version. How do I override this behaviour?
My thoughts so far are:
I could get the package sources, edit the descriptions to give different names and build, in effect, two different packages. I'd rather be able to work directly with the binaries though, as it is much less hassle.
I don't necessarily need to have both versions of the packages loaded at the same time (just installed somewhere at the same time). I could perhaps mess about with Sys.getenv('R_HOME') to change the place where R installs the packages, and then .libpaths() to change the place where R looks for them. This seems hacky though, so does anyone have any better ideas?
You could selectively alter the library path. For complete transparency, keep both out of your usual path and then do
library(foo, lib.loc="~/dev/foo/v1") ## loads v1
and
library(foo, lib.loc="~/dev/foo/v2") ## loads v2
The same works for install.packages(), of course. All these commands have a number of arguments, so the hooks you aim for may already be present. So don't look at changing R_HOME, rather look at help(install.packages) (assuming you install from source).
But AFAIK you cannot load the same package twice under the same name.
Many years have passed since the accepted answer which is of course still valid. It might however be worthwhile to mention a few new options that arised in the meanwhile:
Managing multiple versions of packages
For managing multiple versions of packages on a project (directory) level, the packrat tool can be useful: https://rstudio.github.io/packrat/. In short
Packrat enhances your project directory by storing your package dependencies inside it, rather than relying on your personal R library that is shared across all of your other R sessions.
This basically means that each of your projects can have its own "private library", isolated from the user and system libraries. If you are using RStudio, packrat is very neatly integrated and easy to use.
Installing custom package versions
In terms of installing a custom version of a package, there are many ways, perhaps the most convenient may be using the devtools package, example:
devtools::install_version("ggplot2", version = "0.9.1")
Alternatively, as suggested by Richie, there is now a more lightweight package called remotes that is a result of the decomposition of devtools into smaller packages, with very similar usage:
remotes::install_version("ggplot2", version = "0.9.1")
More info on the topic can be found:
https://support.rstudio.com/hc/en-us/articles/219949047-Installing-older-versions-of-packages
I worked with R for a longtime now and it's only today that I thought about this. The idea came from the fact that I started dabbling with Python and the first step I had to make was to manage what they (pythonistas) call "Virtual environments". They even have dedicated tools for this seemingly important task. I informed myself more about this aspect and why they take it so seriously. I finally realized that this is a neat and important way to manage different projects with conflicting dependencies. I wanted to know why R doesn't have this feature and found that actually the concept of "environments" exists in R but not introduced to newbies like in Python. So you need to check the documentation about this and it will solve your issue.
Sorry for rambling but I thought it would help.