Can someone clear up how the working directory affects debugging in rmd files. I have a project which includes an rmd file. The rmd file starts with some parameters:
params:
filtered_obs: "inst/data/filtered_obs.csv"
And in the code, let's take the following line:
wrangled_devices <- wrangle_devices(params$filtered_devices)
This works when I deploy the code and run it. I can also copy and paste the above command onto the console and it runs fine. The working directory is set to the project directory, which lines up correctly with the relative path given to the parameter.
However, when I step through the code in the rmd file, using ctrl + enter, I get the following error:
> getwd()
[1] "D:/MonkeySource/2 Cloud/cdk_stacks/docker-images/flexi/monkeyr"
> wrangled_devices <- wrangle_devices(params$filtered_devices)
Error: 'inst/data/filtered_devices.csv' does not exist in current working directory ('D:/MonkeySource/2 Cloud/cdk_stacks/docker-images/flexi/monkeyr/inst').
As you can see the wd is correct in the console, but not correct in the rmd file. It seems like the rmd file assumes the wd is it's own location? Is this correct? This seems really wrong...
If I then click the up arrow on the console and rerun the command (so literally rerunning the last command), it works fine. Obviously the actaul wd applies this time.
> wrangled_devices <- wrangle_devices(params$filtered_devices)
>
My question is - is there a way to control the effective working directory as you issue debug commands using ctrl+enter in rmd files?
Related
Hoping for some help - I have been banging my head for a few hours and I can't find a solution. I am trying to optimise a workflow which involves sourcing a script from a Quarto file (I imagine this would be the same for an R markdown file). If I run the actual script using here() to load csv files, it works perfectly and sets the root directory as:
here() starts at /Users/Jobs/2023/project_x
Which is where the R project file is located.
But if I source that same script from within a Quarto file it sets the root directory to one up from the folder containing the .qmd file, and prevents the csv files from being able to be read:
here() starts at /Users/Jobs/2023/project_x/Analysis/code
The .qmd file is located at:
here() starts at /Users/Jobs/2023/project_x/Analysis/code/rmd
Is this expected behaviour and can I get around it?
Using:
here::set_here("/Users/Jobs/2023/project_x")
in a .qmd code chunk seems to work and keep all paths using here() intact in the source script, but I don't think it's ideal as I still need to specify an absolute path in the first instance.
Open to other suggestions...
I'm working on a project involving several people. We are using GitHub and a Rproject to be able to work on this project on different computers.
But I'm facing a really weird issue when I try to load files and/or get my working directory:
When I type getwd() in R console, I indeed get the path where the project is saved on my computer
> getwd()
[1] "/media/Data/Documents/my_R_project"
When I save getwd() in an object, the WD is not the same and now moves to the path were the script are saved:
folderpath <- getwd()
> folderpath
[1] "/media/Data/Documents/my_R_project/R/Script"
I get the same issue when I try to load a file which is located in /media/Data/Documents/my_R_project/R/Data: when I use read_csv (or any other function like it) and write the file path as
read_csv("R/Data/file.csv") I get and error stating me that there is no such file in the directory /media/Data/Documents/my_R_project/R/Script/R/Data/.
How could I resolve this and make the WD used in read_csv() be the right one ("/media/Data/Documents/my_R_project") so that I don't have to specify the full path every time and that people on another computer can run my script?
I'm working on Ubuntu LTS 20.04
In the end, the error was due to a conflict between the WD of the project and the WD used when I knitted the .Rmd file. The problem was solved by changing the knit options and set its directory as the project directory.
When I run the following code I get an error.
library(tidyverse)
day <- read.csv("day.csv")[, -1]
glimpse(day)
Result:
Show in New Window
Error in file(file, "rt") : cannot open the connection
However when I specify the file path it works:
library(tidyverse)
setwd("~/UofUProjects/IS6489")
day <- read.csv("day.csv")[, -1]
glimpse(day)
I don't want to have to specify the file path for every single code chunk I run. Is this a setting I may have accidentally disabled? I tried deleting an re adding the file. I also tried clicking more and choosing set working directory and I still get the same error. I also tried updating Rstudio and R to the newest versions.
here is my working directory
The R markdown file I was using was saved in my download folder instead of my project folder. I was trying to specify the working directory folder with the R studio settings, and thought it would recognize however it did not work unless I actually saved the R markdown file in the project folder or used setwd(). I ran the code without the setwd() after I saved in the correct location and it worked just the way I wanted it to.
I have successfully run a simple cronR tutorial using the cronR add in within R Studio. Here is the following code that I have saved in a R script file:
library(glue)
current_time <- Sys.time()
print(current_time)
msg <- glue::glue("This is a test I am running at {current_time}.")
cat(msg, file = "test.txt")
The R script file is saved within a specific project directory. The log file when the job runs is also saved there. However, the output of the script file, test.txt, is saved in my home directory. I am on a Mac. In the tutorial, it was stated that this would happen, that cron would save any output in the home directory and that if I want to change the location that I have to "specify otherwise". However, the tutorial gives no instructions for how to do this and I am not sure if I am supposed to do this through the terminal in mac and if so how? Changing the file path in the script file (e.g. Documents/test.txt) changes nothing, as the test.txt file is still saved in the home drive. I suspect I have to make this change somewhere else but I am not sure where. Any help would be appreciated.
For anyone who runs into the same issue, I was able to solve my problem by using launchD. I followed this tutorial https://babichmorrowc.github.io/post/launchd-jobs/. It worked as anticipated and now my .txt file is saved to the correct place. There is also a tutorial there for cron jobs, though if you are on a mac, launchD is apparently the preferred method.
I have two projects in R. I've moved an .Rmd document from project 1 to project 2.
When I used the .Rmd file which I had moved to project 2 to try and read in some data I get the following error message:
cannot open file '"mydata.csv"': No such file or directoryError in file(file, "rt") : cannot open the connection.
This kind of error usually suggests to me it's a working directory issue, however when I run getwd() in the command line it's the correct working directory that is listed and points to where the csv is stored. I've also run getwd() within the rmd doc and again the wd is correct.
Does anyone else have this experience of moving one .Rmd file to another project and then it not working in the new project?
The code in the .Rmd file that I am trying to run is:
Data <- read.csv("mydata.csv", stringsAsFactors = T) and the data is definitely within the project and has the correct title, is a csv etc.
Has anyone else seen this issue when moving an RMarkdown document into another project before?
Thanks
This may not be the answer, but rmarkdown and knitr intentionally don't respect setwd(): the code in each block is run from the directory holding the .rmd file. So, if you've moved your .rmd file but are then using setwd() to change to the directory holding the data, that does not persist across code chunks.
If this is the issue, then one solution is to use the knitr options to set the root.dir to the data location:
opts_knit$set(root.dir = '/path/to/the/data')
See here.
Maybe not relevant but it seems to be the most likely explanation for what's happening here:
The project shouldn't really interfere with your code here. When opening the project it will set your working directory to the root location of the project. However, this shouldn't matter in this case since RMarkdown files automatically set the working directory to the location where the RMarkdown file is saved. You can see this when running getwd() once in the Console and once from the RMarkdown file via run current chunk.
The behavior is the same when the file is knitted. So except in the case when "mydata.csv" is in the same directory as the RMarkdown file, the code above won't work.
There are two workarounds: you can use relative or absolute paths to navigate to your data file. In a project I prefer relative paths. Let's say the rmd file is in a folder called "scripts" and your data file is in a folder called "data" and both are in the same project folder. Then this should work:
Data <- read.csv("../data/mydata.csv", stringsAsFactors = TRUE)
The other option, which I do not recommend, is to set the working diretory in the rmd file via:
opts_knit$set(root.dir = '../data/')
The reason why I wouldn't do that is because the working direcotry is only changed when knitting the document but using the rmd file interactivly, you have a different working directory (the location of the rmd file)
This is a great application of the here package for dealing with these types of issues.
here https://github.com/jennybc/here_here looks around the Rmd file (and all R files) for the .Rproj file and then uses that as an "anchor" to search for other files using relative references. If for instance you had the following project structure:
-data
|--mydata.csv
-src
|-00-import.R
|-01-make-graphs.R
|-02-do-analysis.R
-report
|--report.Rmd
-yourproject.Rproj
And you wanted to use mydata.csv in your report.Rmd you could do the following:
library(here)
dat <- read.csv(here("data", "mydata.csv"))
here will then convert this path to "~/Users/../data/mydata.csv" for you. Note that you have to be in the Rproject for this use case.
Here is such a great package and solves a lot of issues.