I'm trying to dev a julia package. I have it in ~/.julia/dev/<PackageName>, and I'm testing the modifications that I make to it in another REPL, using Pkg.develop() and Pkg.free() to switch to and from the development version of the package.
The problem is that I don't seem to be able use the most recent changes (not commited) I made to the package by using Pkg.develop(). What am I doing wrong? is there a way to avoid commiting the package changes before testing them? What is a good workflow for deving and testing packages?
Cheers
I am new to R and just wondering if for every dataset I need to work on, I need to re-install tidyverse? I noticed that on the google Data Analytic program, we are always asked to install. Package("tidyverse")
No, you only have to install it once. The program suggests installing it every time to make sure you get it if you don't already have it.
After the first time you install it, it becomes part of your package library, so it is available for scripts to use as long as the package library remains accessible. You can read more about packages and libraries here:
https://hbctraining.github.io/Intro-to-R-flipped/lessons/04_introR_packages.html
I'm currently trying to download some of the packages here, though it mentions that they're not available in R when I type for example, install.packages("ssM8") into the console.
Now, it doesn't look like these packages are deprecated, as the pdf for the package ssNZ has been updated since yesterday, although, I cannot seem to install this also.
Perhaps, there is another method for installing these packages? I appreciate your comments, as I may have missed something out.
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.
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.