I have set up a workflow governed by a Makefile.
Under code/ I have multiple *.r scripts each typically responsible for creating one output file (typically an RData file but could also be csv exports or png images, any file in principle)
code/.Rprofile contains some helper functions to bootstrap the whole project directory system and sources some helper functions etc.
The scripts in code/ need this functionality to work properly.
RStudio has the convenient menu entry to set working directory to source file location.
But could I also make it run .Rprofile in that directory if found? Or really just start R a fresh from the directory of the source file?
Related
I have main directory with R project file, project is called "knn". I have subdirectories source (contains all .R files), data (contains .csv files used in project) and man (.Rd files should go there). I also have correct DESCRIPTION and NAMESPACE (generated by Roxygen) files in main directory.
When I use roxygen2::roxygenize() in my main project directory, I get Loading knn and no files. When I use devtools::document() in my main directory, I get Updating knn documentation Loading knn. I have no documentation or .Rd files whatsoever.
I've even tried moving all my .R files to main directory - same results. How can I generate my documentation? What am I doing wrong?
As commented, Roxygen assumes all your .R scripts are in a directory called R.
As explained by Yihui Xie in this post, when one uses the Compile PDF button of the RStudio IDE to produce a PDF from a .Rnw file, knit() uses the globalenv() of a new R session. Is there a way that this new R session would use the packrat libraries of my project (even the version of knitr included in my packrat libraries) instead of my personal user libraries to ensure a maximum level of reproducibility? I guess that the new R session would have to be linked to the project itself, but I don't know how to do this efficiently.
I know I could directly use the knit() function instead of the Compile PDF button and, that way, knit() would use my current globalenv(), but I don't like this solution since it's less reproducible.
I think I got the problem myself, but I want to share with others who could confirm I'm right, and possibly help improve my solution.
My specific problem is that my .Rnw file is in a sub-directory of my whole project. When the Compile PDF button creates a new R session, it is created in this sub-directory, thus not finding the .Rprofile file that would initialize packrat. I think the easiest solution would be to create a .Rprofile file in my subdirectory which contains
temp <- getwd()
setwd("..")
source("packrat/init.R")
setwd(temp)
rm(temp)
I have to change the working directory at the project level before source("packrat/init.R") because the file itself refers to the directory...
Anybody can see a better solution?
P.,
I don't know if this solution works for even the knitr package, but I am 99% sure it works for all other packages as it seems to for me.
(I believe) I have a very similar problem. I have my project folder, but my working directory has always been the sub folder where my .rnw file is located, in a subdirectory of my project folder.
The link to Yihiu Xie's answer was very helpful.
Originally I wanted a project folder such as:
project-a/
working/
data/
datas.csv
analysis/
library.R
rscripts.R
rnw/
report.rnw
child/
preamble.rnw
packrat/
But I'm not sure if that is possible with packrat when my R library() calls are not in the working directory and packrat cannot parse the .rnw file (I call the library.R file from a chunck using source() in my .rnw file). A few notes:
I wanted to use a .Rproj file to open the project and have project-a/working as the working directory
If this was true then packrat can find the library.R script
But the .rnw file still defaults to its own working directory when compiling
I thought an .Rprofile with knitr::opts_knit$set(root.dir = "..") would work but I don't think it works for latex commands like input\, it defaults back to the directory containing the .rnw file
I thought this was insufficient because then you have two working directories, one for your r chunks and one for your latex!
Since .rnw always sets the working directory, I put my library.R script in the same directory as my .rnw file which creates the packrat folder in project-a/working/rnw. I am 99% sure this works because when I created the packrat folder in the project-a/working/rnw folder WITHOUT relocating the library.R file it received an error that no packages could be found and I could not compile the .rnw file.
project-a/
working/
data/
datas.csv
analysis/
rscripts.R
rnw/
report.rnw
library.R
packrat/
child/
preamble.rnw
Again, unless I am overlooking something or misunderstanding which packages are being used, this seems to have worked for me. Disclaimer here that I am relatively new to packrat.
There is a CSV file called orders_data stored in my system, but when I try to load this file in Julia using readdlm command in Jupyter Notebook(running in my browser), it says "NO SUCH FILE DIRECTORY FOUND"
I'm not sure why does this happen? is there a specific location where the files need to be stored to be accessed using Julia command? is it that I need to install some packages first to load the file using browser version of jupyter?
//Error information
SystemError: opening file orders_data.csv: No such file or directory
Your working directory is set to your current location when you start a Julia session. You can see what it is by calling the pwd() function. You can change it by calling the cd() function. Unless you specify otherwise, or provide a more complete pathname, Julia looks for files in your current working directory (although it's different for modules).
I'm working in Rstudio and have multiple scripts open that have different working directories; however, each working directory exists within a larger folder on my computer (see below). Is it possible to add these scripts to an Rstudio Project without reorganizing all my files and changing each script's working directory?
File structure on computer:
Folder A
~~Folder 1
~~Folder 2
~~Folder 3
Say I have 3 scripts open, each with a working directory of either Folder 1, 2, or 3. Can I create a project that incorporates all three scripts. Say, set working directory to "Folder A"
Thanks much.
Technically, you can change working directory programmatically within a project, but this is considered a very poor practice and is strongly recommended against. However, you can set working directory at a project's top level (full path to Folder A, in your example) and then refer to scripts and objects, located in Folders 1-3 via corresponding relative paths. For example: "./Folder1/MyScript.R" or "./Folder2/MyData.csv".
It should be possible to create a project in the larger folder. You could even construct a simple master script in Folder A to manage this workflow:
setwd("./Folder 1")
source("scriptx")
setwd("..")
setwd("./Folder 2")
source("scripty")
setwd("..")
setwd("./Folder 3")
source("scriptz")
setwd("..")
Compared to source("Folder 1/scriptx") which runs each script within Folder A the master script would be running each script within it's own folder. Just make sure to use setwd("..") after running code in each folder and you can even run code in between to save output to the main Folder A.
If your workflow always creates folders in this manner I don't see how this would not be reproducible if you used relative paths. Albeit platform dependent, this modified version would create folders on the fly and run scripts kept in Folder A.
system("mkdir Folder_1")
setwd("./Folder_1")
source("../Folder A/scriptx")
setwd("..")
Notice here that when running terminal commands in R, it is recommended avoid spaces in directory or file names.
How do I start a new .R file default in a new session for new objects in that session?
Workspaces are .RData files, not .R files. .R files are source files, i.e. text files containing code.
It's a bit tricky. If you saved the workspace, then R saves two files in the current working directory : an .RData file with the objects and a .RHistory file with the history of commands. In earlier versions of R, this was saved in the R directory itself. With my version 2.11.1, it uses the desktop.
If you start up your R and it says : "[Previously saved workspace restored]", then it loaded the file ".RData" and ".RHistory" from the default working directory. You find that one by the command
getwd()
If it's not a desktop or so, then you can use
dir()
to see what's inside. For me that doesn't work, as I only have the file "desktop.ini" there (thank you, bloody Windoze).
Now there are 2 options : you manually rename the workspace, or use the command:
save.image(file="filename.RData")
to save the workspaces before you exit. Alternatively, you can set those options in the file Rprofile.site. This is a text file containing the code R has to run at startup. The file resides in the subdirectory /etc of your R directory. You can add to the bottom of the file something like :
fn <- paste("Wspace",Sys.Date(),sep="")
nfiles <- length(grep(paste(fn,".*.RData",sep=""),dir()))
fn <- paste(fn,"_",nfiles+1,".RData",sep="")
options(save.image.defaults=list(file=fn))
Beware: this doesn't do a thing if you save the workspace by clicking "yes" on the message box. You have to use the command
save.image()
right before you close your R-session. If you click "yes", it will still save the workspace as ".RData", so you'll have to rename it again.
I believe that you can save your current workspace using save.image(), which will default to the name ".RData". You can load a workspace simply using load().
If you're loading a pre-existing workspace and you don't want that to happen, rename or delete the .RData file in the current working directory.
If you want to have different projects with different workspaces, the easiest thing to do is create multiple directories.
There is no connection between sessions, objects and controlling files .R. In short: no need to.
You may enjoy walking through the worked example at the end of the Introduction to R - A Sample Session.
Fire up R in your preferred environment and execute the commands one-by-one.