I am writing an R package in which you can make networks and output them in different file-types. I found the package SVGRTipsDevice which can be used to create SVG pictures containing tooltips and hyperlinks, which I really like. I have included this in my package as one of the options to output in, making it not an essential part of my package, but a part of it nonetheless (one that I want to keep).
The problem now is, that this package is for 32bit users only. Because my package depends on it 64bit users are not able to install it. it seems that I either have to make my package 32bit-only as well or remove the SVG abilities (currently I chose the latter to upload to CRAN, with a link to the full package on my site).
Is there any way to do this differently? Like making the package installable for anyone but only make the SVG functionality available for 32bit users?
easiest way I can think of is to check Sys.info() for the machine type:
So on my machine:
Sys.info()["machine"]
machine
"x86_64"
EDIT I believe that tells us the architecture of the hardware, not whether R is 32 or 64 bit. So if a user had 64 bit hardware and was running 32 bit R, the above code would still return x86_64 As Sacha pointed out to me, a better solution is to run:
R.Version()$arch
[1] "x86_64"
So you can see I'm running a 64 bit OS AND I am running the 64 bit version of R.
Packages listed in the Suggests: or Enhances: field of the DESCRIPTION file of your package do not need to be installed on the user's system for your package to be installed, so that 32/64 bit users can install your package. Rather than testing for bit-ness, you might ok <- suppressWarnings(require(SVGToolTips))), maybe in .onLoad or similar.
You could make a packagename-32bit package also with the extra functionality.
Related
I used to use R in RStudio which make it easer to handle.
As I got a bigger data I got access to a HPC of the university through SSH interface (MobaXterm) which could be done using terminal as well.
My problem is my inability to access to the administration, which prevent me from installing packages. And I'm pretty sure that I need to change one of the libraries directory that I don't have access to it.
.libPaths()
[1] "/home/UserIsMe/R/x86_64-pc-linux-gnu-library/4.2"
[2] "/cm/shared/apps/R/4.2.1/lib64/R/library"
Is there any way to change the second directory to mine (like the first).
NB: I found a trouble even when I'm trying to install packages from linux's terminal.
When I run install.packages("somepkg") on Linux (Ubuntu mostly), the installation process invovled building the R package from source which can be time consuming. Also it can be prone to failure due to missing development related Linux packages.
Is there a way to install compiled binaries like on Windows? I heard that it can be done, but couldn't find an easy to understand resource. Hope by asking here I will make the answer (if it exists) more googlable.
It depends on whether binaries exist. Which, in turn, depends on which Linux distro and version you are running.
For Ubuntu 18.04 (and later, as they are compatible), you can use the Rutter PPAs which cover over four thousand CRAN package. This is described (albeit very briefly) at the top of this README at CRAN.
I also blogged about that (a few times) below my r4/ tag -- and because it didn't really "stick" amplified it again with short video plus slides, see this post. The video runs for about 5 mins during which we install rstan and tidyverse as binaries each with just one command and it takes about a good minute each (depending on bandwidth and disk speed, of course) pulling all dependencies in pre-built and in a fail-safe manner.
If this matches your needs, give it a try and please come to to the r-sig-debian list for questions.
If you are on a different Linux flavor then I unfortunately less sure if a comparable service exists.
Edit on 2020-09-17 As this was just upvoted and I was thus reminded of it, you now have better options and can get Linux binaries via install.packages("pkgname"). One way is RSPM, the other is BSPM. I have a first comparison blog post comparing both here (even with animated gif movies ;-)) and should be able to say more about BSPM "soon".
Edit on 2022-08-03 And going beyond RSPM and BSPM is the newer r2u which has been up for a few months and is currently serving around two thousand binaries a day. It is the best approach for binaries on Ubuntu LTS installations (currently: 20.04 and 22.04). See r2u for more including demos.
i've been getting up to speed using R of late, and am wondering what the most efficient way is to clone an RStudio environment, especially the package installations, from one machine to another. i'd like to be able to switch from my desktop machine to my laptop, but i am adding packages very frequently to the desktop as i work and would like a simple way to make sure the same packages get installed on the laptop.
any help much appreciated
ps. not everything i'm installing is from CRAN...some are packages taken from github
If you have more than a couple of machine to maintain with the same R configuration, I think you should consider setting up your own local R repository.
And I will just redirect you to another SO question here:
Creating a local R package repository
You can also find the most useful information in the R manual.
Once this is done, you just have to update the local R repository and the packages will be updated on all machines, Windows or Unix
You can just copy and paste the folders in the R libraries between machines. As long as it is the same operating system on both machines there should not be any problem. If you want it to be automatically synchronised then place the R libraries into something like dropbox so that adding or updating a package will automatically appear on either machine with the next sync.
I'm trying to write some SPARQL queries in R using the rrdf package. However, I get this error every time I try to load the library.
Error: package 'rrdflibs' 1.1.2 was found, but == 1.1.0 is required by 'rrdf'
Not sure why they didn't write it as >= 1.1.0. Is what they did a good programming practice?
Go to http://cran.r-project.org/src/contrib/Archive/rrdflibs/ to retrieve an older version. This is a source archive, so you will have to be able to build from source (typically easy on Linux, pretty easy on MacOS, and hard on Windows; you can use the http://win-builder.r-project.org/ service to build a Windows binary if necessary).
Actually, based on a quick look at the package, I think you should be able to install in this case (even on Windows without Rtools) via
download.file("http://cran.r-project.org/src/contrib/Archive/rrdflibs/rrdflibs_1.1.0.tar.gz",
dest="rrfdlibs_1.1.0.tar.gz")
install.packages("rrfdlibs_1.1.0.tar.gz",repos=NULL,type="source")
because the package doesn't actually contain anything that needs to be compiled.
Don't know about programming practice, you'd have to ask the authors if they had some particular reason to do it that way. (See maintainer("rrdf").) Maybe they knew the versions would not be backward/forward compatible?
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.