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.
Related
I recently began receiving warnings that prior installations of R packages cannot be removed when I try to re-install packages:
install.packages("gtools")
#> Warning: cannot remove prior installation of package ‘gtools’
#> Warning: restored ‘gtools’
I found solutions to this issue encouraging me to delete the packages manually from my library folder, which I could find with .libPaths(). However, (a) this seems like a way of addressing symptoms rather than the underlying issue (which remains unclear) and (b) there are two paths for seemingly different versions of R and I'm not sure which to delete from anyway:
.libPaths()
#> [1] "C:/Users/foo/Documents/R/win-library/4.1"
#> [2] "C:/Program Files/R/R-4.1.2/library"
How can I fix the problem so I don't have to manually delete package folders every time I want to re-install a package? If there is no alternative, do I need to delete the subdirectories for the package from one of those folders or both? FWIW, I'm working in RStudio.
The problem is that you have installed packages using different permissions. On Windows, you need elevated permissions to write to Program Files. At some point you (or an admin) probably used "Run as admin" to install gtools there, and now using regular permissions you can't delete that.
You should be able to delete the Users/foo copy, if you are running as user foo, but even that one may have had permissions changed. But I'd guess the issue is that gtools is in the Program files location.
The error message from R doesn't tell you which location it is trying to delete from, which is unfortunate. In fact, allowing installations of different versions in those two locations is a bad design feature in R that just leads to confusion, because you don't necessarily always use the same version each time you load packages. (The rule for which one you use is the first acceptable one found in the .libPaths list, but since you can change .libPaths, and since packages can load other packages, it's hard to predict which one you'll have loaded at any given time.)
To fix this, you can delete both copies (if you have two) and start over, but that's risky because other packages might be depending on gtools. If you are the only user on your computer, you could instead delete the entire "C:/Users/foo/Documents/R/win-library/4.1" library, and then do all your installs using "Run as admin", but that's also easy to mess up.
(On a Mac, that's effectively what happens, because most single user systems put the user in the "admin" group, so they can always install packages to the system location. It causes a lot less confusion, but some "purists" think the Windows way is better.)
So I don't have any good advice for you, but maybe this explains the situation, and you can work out for yourself the best way forward.
Currently I'm calling for install.packages() every time I'm loading a library in R, since my laptop seems to always giving me an error message if I don't do that, but I'm kinda sure that I've already installed those packages while setting up RStudio. Is there a way for me to enter those install.packages() on top of every RMD file and then hide them? I've heard that some code could do it. Thanks a lot!
You don't need to install a package each time. Simply run library(whateverpackage) and that's it. You can always suppressMessages(library(whateverpackage)) You can see currently loaded packages using sessionInfo()
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.
Can anybody give me some direction on editing source code of an R package? From what I've seen, changing the package from within R does not seem to be possible. In editing outside of R, I'm stuck at unpacking the tar.gz. While I can now modify the function to my heart's content, the folder looks nothing like the working snow library. I presume I will need to turn the contents into a tar.gz once again and install it in the standard way?
My colleagues and I have been attempting to get makeSOCKcluster() to work with remote IPs for the past three days. Hangs indefinitely. After digging into the snow package I've found the issue to be in the way newSOCKnode() calls socketConnection(). If I run makeSOCKcluster("IP", manual=T) and then put the output into powershell, it results in the connection being made but the program not completing. However, I can run makeSOCKcluster("IP", manual=T) in one R instance and then run system("output", wait=F, input="") in another instance which results in the program completing. I believe I can simply modify snow to do this automatically.
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.