Thank you for this package, excellent use for reproducible scripts!

There is a conflict with the plyr package (see here {plyr}). That happens only if you load the 'here' package before 'plyr'- so the solution is easy- just thought I'd put it out there!

in the documentation.

#18 (comment)

Some of the users with whom I collaborate with have complicated folder structures. We use .git for version control, some use RStudio and so the .rproj etc. can often result in the heuristics playing out in a inconsistent way.

An option to have the .here file override any other heuristics would be a great way to solve this.

Is this possible?

I am trying to convert all my 'projects' to use here() rather than setwd() but am having random problems with the here() function (and others) not loving the .here files. I'm not able to use rStudio etc so don't have any sort of .project files. I am just trying to use a text editor along with a .here file which I can see in windows explorer but here() is sometimes not recognising them. Here's a short script that I have used to reproduce what I am seeing:

setwd("C:/!Rprojects/heretest/src")
library(here)
packageVersion("here")
packageVersion("rprojroot")
sessionInfo()
getwd()
list.files(".")
list.files("..")
set_here("..")
set_here("..")
list.files(".")
list.files("..")
here()
dr_here()

Before running the test script, the main project directory just contains the following:
data - an empty directory
doco - an empty directory
output - an empty directory
src - a directory containing a single R script with the above code

I have opened a fresh R session to run the commands above

setwd("C:/!Rprojects/heretest/src")
library(here)
here() starts at C:/!Rprojects/heretest/src
packageVersion("here")
[1] ‘0.1’
packageVersion("rprojroot")
[1] ‘1.3.2’
sessionInfo()
R version 3.4.3 (2017-11-30)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1

Matrix products: default

locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
[3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252

attached base packages:
[1] stats graphics grDevices utils datasets methods base

other attached packages:
[1] here_0.1

loaded via a namespace (and not attached):
[1] compiler_3.4.3 backports_1.1.2 rprojroot_1.3-2

getwd()
[1] "C:/!Rprojects/heretest/src"
list.files(".")
[1] "heretest.R"
list.files("..")
[1] "data" "doco" "output" "src"
set_here("..")
Created file .here in C:!Rprojects\heretest
set_here("..")
File .here already exists in C:!Rprojects\heretest
list.files(".")
[1] "heretest.R"
list.files("..")
[1] "data" "doco" "output" "src"
here()
[1] "C:/!Rprojects/heretest/src"
dr_here()
here() starts at C:/!Rprojects/heretest/src, because none of the following criteria apply for this directory or any of its parents:

• contains a file .here
• contains a file matching [.]Rproj$ with contents matching ^Version: in the first line
• contains a file DESCRIPTION with contents matching ^Package:
• contains a file remake.yml
• contains a file .projectile
• contains a directory .git
• contains a file .git with contents matching ^gitdir:
• contains a directory .svn
  Use set_here() to create a .here file

So, why does the second set_here() call say that the .here file exists and yet the subsequent here() function and dr_here() do not see it there? It's interesting that the second list.files("..") call also does not show the .here file, even though it's after the set_here("..") calls and the .here file certainly exists at that point.

Now, exiting R and starting a fresh session then running the same commands gives a different result.

setwd("C:/!Rprojects/heretest/src")
library(here)
here() starts at C:/!Rprojects/heretest
packageVersion("here")
[1] ‘0.1’
packageVersion("rprojroot")
[1] ‘1.3.2’
sessionInfo()
R version 3.4.3 (2017-11-30)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1

Matrix products: default

locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
[3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252

attached base packages:
[1] stats graphics grDevices utils datasets methods base

other attached packages:
[1] here_0.1

loaded via a namespace (and not attached):
[1] compiler_3.4.3 backports_1.1.2 rprojroot_1.3-2

getwd()
[1] "C:/!Rprojects/heretest/src"
list.files(".")
[1] "heretest.R"
list.files("..")
[1] "data" "doco" "output" "src"
set_here("..")
File .here already exists in C:!Rprojects\heretest
set_here("..")
File .here already exists in C:!Rprojects\heretest
list.files(".")
[1] "heretest.R"
list.files("..")
[1] "data" "doco" "output" "src"
here()
[1] "C:/!Rprojects/heretest"
dr_here()
here() starts at C:/!Rprojects/heretest, because it contains a file .here

this time through, note the following:

• library(here) has detected the .here file
• set_here("..") fails both times, as expected, because the file exists
• list.files("..") still doesn't detect the file (it should shouldn't it?)
• here() works correctly
• dr_here() works correctly

Is there perhaps some sort of cached directory information that's causing the .here file to be not detected by here() after it's been created by set_here() on the first time through? Maybe? Just guessing.
list.files doesn't seem to like the file either, but that's a different issue, though possibly related.

here() looks really promising and I'm loving the idea. just getting confused in trying to actually use it on windows. thanks for any help.

You will notice my recent ode to here.

When explaining how here::here() "just works", I wished that were even more true, even if someone doesn't use RStudio. My rationale is 50% functionality, 50% optics. This is also why I proposed elevating Git-repository-hood over in rprojroot (r-lib/rprojroot#20). I think it would be a valid heuristic for here, because many people use Git (and/or it's a practice that is easy to recommend!).

What do you think of adding a criterion to here() that just looks for a file named .here, using has_file() under the hood? Plus a simple initializer that just does touch .here. Then it's really easy to make here::here() "just work" for literally anyone, regardless of their IDE.

Currently, if you create a file path to a directory using here(), then it will be expanded to an absolute path. If you try to use here() again with that directory and a file name, then the absolute reference gets repeated.

# define a directory using here() and a file within that directory
my_dir <- here::here("data", "iris")
my_file <- "iris.csv"

# doesn't work
read_csv(here::here(my_dir, my_file))
> Error: '/Users/name//Users/name/data/iris/iris.csv' does not exist.

# works
read_csv(file.path(my_dir, my_file))

I am requesting a feature or better documentation if this feature already exists to be able to append to an absolute path created by here(). I understand if this is out of scope because file.path() can already do this functionality, but it seems reasonable that the here package could have something like "append to path" functionality like this:

my_dir <- here::here("data", "iris")
my_file <- "iris.csv"
read_csv(here::here(my_dir, my_file, append = TRUE))

Thanks a ton for the package. I love it and am following in Jenny's path in advocating its use instead of setwd().

My issue is closely related to jennybc/here_here#3 and #24.

Problem:

You need to create a .here file in a directory because it isn't big nor important enough to justify doing version control on it. But that directory is nested in another one which has a .something file that here will use to set the "project" root. Now, using set_here() will create the .here file just fine, but here has already been set and there is no way to update it unless restarting the R process (which creates a very awkward workflow and impairs automation).

As mentioned in other issues re-running library(here) (which wouldn't be a great solution anyway) has no effect. And I even tried running here::set_here() before running library(here), but that does not work either. Reloading R is the only solution.

Suggestion:

set_here() does what it should and work great when here hasn't been set on a wrong target (due to something higher in the path than the intended project root), but fails when a wrong target was found. Having a function that would automatically run while using set_here() to reset here to the location of the .here file that has just been created would be more robust and cover situations such as the one I am describing.

Often I'm passing filenames through multiple function call, and sometimes I'm extra-careful and wrap that filename in here in multiple places.

> "data/mydata.csv"
[1] "data/mydata.csv"
> 
> here("data/mydata.csv")
[1] "D:/projects/thisproject/data/mydata.csv"
> 
> here(here("data/mydata.csv"))
[1] "D:/projects/thisproject/D:/projects/thisproject/data/mydata.csv"

Probably a little dangerous to pattern-match the first part of the string, but maybe an attribute could be set?

Such a great package. Thank you for developing it.

I am wondering if there are any plans to implement a here class so that we can efficiently get deeper into a directory using a previously defined here object. For example:

> library(here)
> data_dir <- here("data")
> data_dir
[1] "C:/_dev/data"
> data1 <- here(data_dir,"data1","data1.csv")
> data1
[1] "C:/_dev/C:/_dev/data/data1/data1.csv"

I tripped myself up recent when I tried to re-use a path created by here in this manner.

If not can you recommend an alternative approach when you are building paths that go deeper into a directory?

Hello,
I am using here to automate knitr report creation by moving report and data files in separate directories, /reports and /data. The common root is the here directory.

However, I would like to specify a prefix to save knitr figures in subdirectory /reports/fig.
knitr requires a trailing slash to specify directories.
Using here('reports', 'fig/') strips the trailing /, thus e.g., figure img_01.png is outputted as /reports/figimg_01.png instead of /reports/fig/img_01.png.

Currently I have to manually paste: paste0(here('reports', 'fig'), '/'), but this becomes cumbersome.

Thank you!

First of all, thank you to @krlmlr et al. for this great package. I use it daily.

I have made a pull request for a new function here::u_r (see #77).

Not sure if the contributors prefer to discuss/review it in an issue or in the comments for the PR, so I opened both 😅 .

I was inspired to submit the PR after keeping (and using) this function locally for a while, but later reading #41, #28 and #19 (and @krlmlr 's replies to them).

here::u_r()

#' Resets here() root to current or target working directory.
#'
#' If no target root directory is specified, the current working directory will be used.
#' There is no need to restart the session
#' 
#' The function is named:
#'     u_r (as in "here::you_are") in reference to:
#'        1. everyone:'WHY ISN"T THIS INCLUDED IN THE PACKAGE!?'
#'           me: 'Well, here you are.'
#'        
#'        2. user:'Start here() at my cwd.'
#'           here:'OK, here you are.' (anastrophe)
#'
#'     u_r (as in "here::user_reset") in reference to:
#'        1. Providing a quick way for a user to reset the root of here().
#'
#'     u_r (as in "here::unload_reload") in reference to:
#'        1. The method used to change the root of here().
#'
#' Q: Why use this when there's RStudio projects?
#' A: There are certain cases where this method is preferable. 
#'
#'
#' @param target_wd `[character(1)]`\cr
#'   The target root directory to start here() from.
#'   If no target root directory is specified,
#'   the current working directory will be used.
#'
#' @export
#' @examples
#' \dontrun{
#' setwd("/somewhere") # initial working directory.
#' here() # 'here starts at /somewhere/'
#' setwd("/anywhere/else") # change working directory
#' here::u_r() # 'here starts at /anywhere/else'
#'
#' setwd("/somewhere/") # initial working directory.
#' here() # 'here starts at /somewhere/'
#' here::u_r("/anywhere/else") # 'here starts at /anywhere/else'
#' getwd() # "/anywhere/else" 
#' }
u_r <- function(target_wd=getwd()){
    detach("package:here", unload=TRUE)
    if(target_wd==getwd()){
        library(here)
    }
    setwd(target_wd)
    library(here)
}

We are systematically re-licensing tidyverse and r-lib packages to use the MIT license, to make our package licenses as clear and permissive as possible. To do so, we need the approval of all copyright holders, which I have found by reviewing contributions from all all non-RStudio contributors. @nzgwynn, @sharlagelfand, would you permit us to re-license here with the MIT license? If so, please comment "I agree" below.

• @nzgwynn
• @sharlagelfand

through an exported function: #18 (comment).

This package is really great. I have a particular usecase that I would be happy to implement a PR for if you think it fits the package.

I would like here() to be able to return paths relative to the cwd where possible.

My use case is that I have rmds files in src/ eg here(src/rmarkdown.Rmd) that are rendered to eg here(outputs/rmarkdown.md) with files in saved in here(outputs/myfiles), eg outputs/myfiles/figure-1.png.

Ideally I would like to set this in knitr, eg knitr::opts_chunk$set(fig.path = here("outputs/rmd_files/exploratory/")). However this means all figure paths are absolute directories, and this totally breaks the md files when moved outside of my PC. If here could return a relative path, I could ensure that the figure path is where I intend it to be while not breaking the links on upload to github etc.

Again, if you think this is a good idea, I'll submit a PR. If not, I'll engineer my own solution.

Cheers, hope I explained this okay.

It would be interesting to consider an assert_here() function.

Inspired by this Twitter conversation with Emile Latour (@emilelatour).

Problem: you use Projects and the here package and life is awesome. But your collaborator still clicks on an Rmd in the Finder and it just opens in RStudio, in whatever Project (or non-Project) they happen to have open. Now all the path-building code doesn't work as planned when they run chunks interactively (knitting the whole document still works fine for them).

If you want to make a .R or .Rmd file more resilient to this and you feel like the Project's name is pretty stable, you could put here::assert_here("PROJECT_NAME") at the top as a way of raising an alarm when the workflow violates expectations.

assert_here() would be something like assertthat::assert_that(identical(basename(here::here()), “PROJECT_NAME”)).

I am bit puzzled about the way here() breaks the workflow.
When I use several R scripts from different projects in one Session (e.g. RStudio) and I switch between them it seems not to be possible to reset the location of here(). I would have to close the session and start a new one. This is obviously corrupting the workflow since in e.g. RStudio you might have objects in the environment that you have calculated for a long time, saving takes time and additional effort, etc.

If there is no way to do switch the location of here in one session, I would like to request this feature.
Otherwise, the here package is completely useless for my purposes.

While I can expand (tab-out) a path when working interactively in the Console:

The same behavior is not present in the Editor:

My environment:

> RStudio.Version()$version
[1] ‘1.2.1335’
> devtools::session_info()
─ Session info ────────────────────────────────────────────────────────────────────────────
 setting  value                       
 version  R version 3.6.1 (2019-07-05)
 os       macOS Mojave 10.14.5        
 system   x86_64, darwin15.6.0        
 ui       RStudio                     
 language (EN)                        
 collate  en_US.UTF-8                 
 ctype    en_US.UTF-8                 
 tz       America/New_York            
 date     2019-08-08                  

─ Packages ────────────────────────────────────────────────────────────────────────────────
 package              * version   date       lib source        
 assertthat             0.2.1     2019-03-21 [1] CRAN (R 3.6.0)
 backports              1.1.4     2019-04-10 [1] CRAN (R 3.6.0)
 Biobase              * 2.44.0    2019-05-02 [1] Bioconductor  
 BiocGenerics         * 0.30.0    2019-05-02 [1] Bioconductor  
 BiocParallel         * 1.18.0    2019-05-02 [1] Bioconductor  
 bitops                 1.0-6     2013-08-17 [1] CRAN (R 3.6.0)
 broom                  0.5.2     2019-04-07 [1] CRAN (R 3.6.0)
 callr                  3.3.1     2019-07-18 [1] CRAN (R 3.6.0)
 cellranger             1.1.0     2016-07-27 [1] CRAN (R 3.6.0)
 cli                    1.1.0     2019-03-19 [1] CRAN (R 3.6.0)
 colorspace             1.4-1     2019-03-18 [1] CRAN (R 3.6.0)
 crayon                 1.3.4     2017-09-16 [1] CRAN (R 3.6.0)
 DelayedArray         * 0.10.0    2019-05-02 [1] Bioconductor  
 desc                   1.2.0     2018-05-01 [1] CRAN (R 3.6.0)
 devtools               2.1.0     2019-07-06 [1] CRAN (R 3.6.0)
 digest                 0.6.20    2019-07-04 [1] CRAN (R 3.6.0)
 dplyr                * 0.8.3     2019-07-04 [1] CRAN (R 3.6.0)
 evaluate               0.14      2019-05-28 [1] CRAN (R 3.6.0)
 forcats              * 0.4.0     2019-02-17 [1] CRAN (R 3.6.0)
 fs                     1.3.1     2019-05-06 [1] CRAN (R 3.6.0)
 generics               0.0.2     2018-11-29 [1] CRAN (R 3.6.0)
 GenomeInfoDb         * 1.20.0    2019-05-02 [1] Bioconductor  
 GenomeInfoDbData       1.2.1     2019-07-19 [1] Bioconductor  
 GenomicRanges        * 1.36.0    2019-05-02 [1] Bioconductor  
 ggplot2              * 3.2.0     2019-06-16 [1] CRAN (R 3.6.0)
 git2r                  0.26.1    2019-06-29 [1] CRAN (R 3.6.1)
 glue                   1.3.1     2019-03-12 [1] CRAN (R 3.6.0)
 gtable                 0.3.0     2019-03-25 [1] CRAN (R 3.6.0)
 haven                  2.1.1     2019-07-04 [1] CRAN (R 3.6.0)
 here                 * 0.1       2017-05-28 [1] CRAN (R 3.6.0)
 hms                    0.5.0     2019-07-09 [1] CRAN (R 3.6.0)
 htmltools              0.3.6     2017-04-28 [1] CRAN (R 3.6.0)
 httr                   1.4.0     2018-12-11 [1] CRAN (R 3.6.0)
 IRanges              * 2.18.1    2019-05-31 [1] Bioconductor  
 jsonlite               1.6       2018-12-07 [1] CRAN (R 3.6.0)
 knitr                  1.23      2019-05-18 [1] CRAN (R 3.6.0)
 lattice                0.20-38   2018-11-04 [1] CRAN (R 3.6.1)
 lazyeval               0.2.2     2019-03-15 [1] CRAN (R 3.6.0)
 lubridate              1.7.4     2018-04-11 [1] CRAN (R 3.6.0)
 magrittr               1.5       2014-11-22 [1] CRAN (R 3.6.0)
 Matrix                 1.2-17    2019-03-22 [1] CRAN (R 3.6.1)
 matrixStats          * 0.54.0    2018-07-23 [1] CRAN (R 3.6.0)
 memoise                1.1.0     2017-04-21 [1] CRAN (R 3.6.0)
 modelr                 0.1.4     2019-02-18 [1] CRAN (R 3.6.0)
 munsell                0.5.0     2018-06-12 [1] CRAN (R 3.6.0)
 nlme                   3.1-141   2019-08-01 [1] CRAN (R 3.6.0)
 pillar                 1.4.2     2019-06-29 [1] CRAN (R 3.6.0)
 pkgbuild               1.0.3     2019-03-20 [1] CRAN (R 3.6.0)
 pkgconfig              2.0.2     2018-08-16 [1] CRAN (R 3.6.0)
 pkgload                1.0.2     2018-10-29 [1] CRAN (R 3.6.0)
 prettyunits            1.0.2     2015-07-13 [1] CRAN (R 3.6.0)
 processx               3.4.1     2019-07-18 [1] CRAN (R 3.6.0)
 ps                     1.3.0     2018-12-21 [1] CRAN (R 3.6.0)
 purrr                * 0.3.2     2019-03-15 [1] CRAN (R 3.6.0)
 R6                     2.4.0     2019-02-14 [1] CRAN (R 3.6.0)
 Rcpp                   1.0.2     2019-07-25 [1] CRAN (R 3.6.0)
 RCurl                  1.95-4.12 2019-03-04 [1] CRAN (R 3.6.0)
 readr                * 1.3.1     2018-12-21 [1] CRAN (R 3.6.0)
 readxl                 1.3.1     2019-03-13 [1] CRAN (R 3.6.0)
 remotes                2.1.0     2019-06-24 [1] CRAN (R 3.6.0)
 rlang                  0.4.0     2019-06-25 [1] CRAN (R 3.6.0)
 rmarkdown              1.14      2019-07-12 [1] CRAN (R 3.6.0)
 rprojroot              1.3-2     2018-01-03 [1] CRAN (R 3.6.0)
 rstudioapi             0.10      2019-03-19 [1] CRAN (R 3.6.0)
 rvest                  0.3.4     2019-05-15 [1] CRAN (R 3.6.0)
 S4Vectors            * 0.22.0    2019-05-02 [1] Bioconductor  
 scales                 1.0.0     2018-08-09 [1] CRAN (R 3.6.0)
 sessioninfo            1.1.1     2018-11-05 [1] CRAN (R 3.6.0)
 stringi                1.4.3     2019-03-12 [1] CRAN (R 3.6.0)
 stringr              * 1.4.0     2019-02-10 [1] CRAN (R 3.6.0)
 SummarizedExperiment * 1.14.1    2019-07-31 [1] Bioconductor  
 testthat               2.2.1     2019-07-25 [1] CRAN (R 3.6.0)
 tibble               * 2.1.3     2019-06-06 [1] CRAN (R 3.6.0)
 tidyr                * 0.8.3     2019-03-01 [1] CRAN (R 3.6.0)
 tidyselect             0.2.5     2018-10-11 [1] CRAN (R 3.6.0)
 tidyverse            * 1.2.1     2017-11-14 [1] CRAN (R 3.6.0)
 usethis                1.5.1     2019-07-04 [1] CRAN (R 3.6.0)
 vctrs                  0.2.0     2019-07-05 [1] CRAN (R 3.6.0)
 withr                  2.1.2     2018-03-15 [1] CRAN (R 3.6.0)
 workflowr            * 1.4.0     2019-06-08 [1] CRAN (R 3.6.0)
 xfun                   0.8       2019-06-25 [1] CRAN (R 3.6.0)
 xml2                   1.2.1     2019-07-29 [1] CRAN (R 3.6.1)
 XVector                0.24.0    2019-05-02 [1] Bioconductor  
 yaml                   2.2.0     2018-07-25 [1] CRAN (R 3.6.0)
 zeallot                0.1.0     2018-01-28 [1] CRAN (R 3.6.0)
 zlibbioc               1.30.0    2019-05-02 [1] Bioconductor  

[1] /Library/Frameworks/R.framework/Versions/3.6/Resources/library

Inspired by jennybc/here_here#3 (comment): Perhaps dr_here() should tell the user that the working directory has changed since the package was loaded? Or at least print the w.d. that was effective when the package was loaded?

@jennybc: What do you think?

Is there a version incompetency with newest R/Rstudio version and the here package?
I am getting the following error:

> library(here)
> here()
[1] "2019-06-17 22:12:53 PDT"
Warning message:
'here' is deprecated; use 'now' instead. Deprecated in version '1.5.6'. 

here is my session.info():

sessionInfo()
R version 3.6.0 (2019-04-26)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS High Sierra 10.13.6

First, thank you for an excellent package.

Second, is there a way to allow for RegEx inside here? I am looking to delete some files automatically once I have processed them, but the file extension case varies. Some are ".zip", and others are ".Zip", etc. I could write one unlink for each case combination, but allowing something like

unlink(here("data", "*.(?i)zip))"

would be great. The "*" part works, but the (?i) part does not.

I have a sub-directory "results". When trying to read in a file from there, here sometimes works but often I get the following error message. Nothing pops up on a google search.

tmp <- read_csv(here("results", "soilSUM.csv"))
Error in here("results", "soilSUM.csv") :
unused arguments ("results", "soilSUM.csv")

The here::here() command returns a string without escaped spaces in paths which contain them.

flights_path <- here::here("data", "flights.csv")
> 
> flights_path
[1] "/Volumes/2021/Spring/CSCI E 497/CTP Proposal/data/flights.csv"
> 

Which should be:

"/Volumes/2021/Spring/CSCI\ E\ 497/CTP\ Proposal/data/flights.csv"

I have been using here within an Rmarkdown file for over a month, and it has been working fine and all of a sudden it stopped working yesterday. Nothing has changed, no new versions of R or the here package, and I don't understand what could have possibly changed. I've checked a couple of different projects that use here and they all seem to be having the same problem. This is how project directory is organized.

| rootDir/
|
|---- rootDir.Rproj
|
|---- Data/
|---- ---- data1.rds
|
|---- Code/
|---- ---- doc1.Rmd

I know that when using Rmarkdown/knitr the default directory is the file that the rmd file lives in, because of this I typically run there here command in this way.
library(here) df <- readRDS(here("../Data/data1.rds"))

In an interactive session df <- readRDS(here("./Data/data1.rds")) works fine.

This is no longer working and I don't understand why. Running here::dr_here() while kniting returns this
here() starts at .../Desktop, because none of the following criteria apply for this directory or any of its parents:

I've tried adding a .here file to both the rootDri and the Code directory, and neither of these worked either.

I find myself doing things like this:

PROJ_ROOT <- here::here()
stopifnot(normalizePath(PROJ_ROOT) != normalizePath(getwd()))

Do you think it would make sense to add an option making here more strict? Or should I just be using rprojroot::find_root if I want that level of control?

Thank you for the package. Fyi, after updating rprojroot yesterday I needed to go back to scripts to specify here::here() while using lubridate

I am encountering issues with here::here() not being able to find the root directory of a package when it's called from inside the tests/testthat folder.
I have a .here file, a DESCRIPTION file, and an Rproj file two levels up from the tests/testthat as one might expect, but dr_here indicates the following:

- contains a file `.here`
- contains a file matching `[.]Rproj$` with contents matching `^Version: ` in the first line
- contains a file `DESCRIPTION` with contents matching `^Package: `
- contains a file `remake.yml`
- contains a file `.projectile`
- contains a directory `.git`
- contains a file `.git` with contents matching `^gitdir: `
- contains a directory `.svn`

It seems like it's not traversing up the tree to the proper parents given this output.
The following does work to find the root directory however:

rprojroot::find_root_file(criterion = rprojroot::has_file("DESCRIPTION"))

would show the reason why here thinks here is here.

Hello, I am having trouble with here() on my windows 10 machine. I believe the problem stems from my use of it with google drive. The package and R are both up to date. I am using r studio. When I run a "here()" call from my google drive files, here often fails to find my project folder. Instead, it starts looking for a project in my C drive. This is even if I restart my r session and only have files from my google drive folder open. It's strange, because if I right-click the file and ask Rstudio to "copy path" for the file, it correctly identifies the google drive location. However, if I then run here::here() from the file, it spits out an entirely different and incorrect location. Any suggestions as to what the issue might be? Thanks!

When running all chunks of my .Rmd file ("Run All"), here() is set to the R-project root dir. All paths are relative to this directory. Let's call it "main-dir".

The .Rmd file is placed one dir below the project root, let's say in "main-dir/sub-dir". When I knit the .Rmd file, I get .local object errors because knitr uses "sub-dir" as root dir when knitting.

Currently my workaround is to use a second R-project in "sub-dir" to ensure that both knitting and running all chunks works with the same relativ paths (and that my folder structure does not get messy).

I wonder what I'm doing wrong here so that here() is not adjusting paths correctly in my case. I initially expected that here() is setting the working directory to the project root when knitting. Did I get this wrong? 😅

Currently doesn't seem to change the here() output when changing directories - which is fine by design, however, if you need to change folders/projects there's no way to force a change in the here() reference.

here()  # outputs: /path/to/project_root
setwd('path/to/new_project_root')
here()  # still outputs: /path/to/project_root

## proposed:
change_here('/path/to/new_project_root')
here()  # outputs: /path/to/new_project_root

Might there be room for a change_here() function that forces a change in directory or something similar? (I'd prefer a reference to Oasis' "Be Here Now" but that might be too long).

The master branch of this repository will soon be renamed to main, as part of a coordinated change across several GitHub organizations (including, but not limited to: tidyverse, r-lib, tidymodels, and sol-eng). We anticipate this will happen by the end of September 2021.

That will be preceded by a release of the usethis package, which will gain some functionality around detecting and adapting to a renamed default branch. There will also be a blog post at the time of this master --> main change.

The purpose of this issue is to:

• Help us firm up the list of targetted repositories
• Make sure all maintainers are aware of what's coming
• Give us an issue to close when the job is done
• Give us a place to put advice for collaborators re: how to adapt

message id: euphoric_snowdog

Small editor nit: The https://krlmlr.github.io/here/ site says here isn't on CRAN yet.

fs is a new package (soon to be submitted to CRAN) for handling file-system operations. It might be nice to add some here integration so that you can do (e.g.) here::here_list(..) as a shortcut for fs::dir_list(here::here(...)).

Hi, I love here() and use it a lot. I just thought that it would be super cool to be able to get autocomplete/suggestions for file paths as it works outside of here().

Or is there a trick how that's already possible?

Thanks :)

The below is what I get when I run the command. here::here() seems to work without the .Rproj file though.

> here::i_am("README.Rmd")
Error: Could not find associated project in working directory or any parent directory.
- Path in project: README.Rmd
- Current working directory: [path]
Please open the project associated with this file and try again.

> here::dr_here(show_reason = TRUE)
here() starts at [path].
- This directory contains a directory ".git"
- Initial working directory: [path]
- Current working directory: [path]

Hi,

I believe since here as been moved to r-lib 2 years ago (19ef731), there has been no CRAN release since because the CRAN page still contains the urls pointing to old documentation site and repo. See https://cran.r-project.org/web/packages/here/index.html

I often go to the CRAN page to find the link of the pkgdown website, and currently, it is 404 because not the correct one and not redirection. I may be the only one but I think it worth sharing this.

• Just realised we have the tidytemplate applied to rprojroot and here packages, which are, in fact, r-lib packages! 😳

here() keeps consecutive separators, and it allows mixing slashes and backslashes. It would be nice to be able to specify an option "standardize" or likewise, to get a clean path with no duplicate separators and only forward slashes (or only the operator system's "prefered" separator).

Most of the contents of https://github.com/jennybc/here_here should be part of the README and/or the "Get started" article. The drawing by @allisonhorst could also be added/referenced?

CC @jennybc

A helper function that adds here::i_am() calls to all files in a project or to the active file.

• If a DESCRIPTION is present, files in the R/ subdirectory should be ignored
• Create a uuid argument with uuid::UUIDgenerate()
• Add to the first line in an R script or to the first line of the first chunk
• If a call to here::i_am() is found, does it need to be moved to the top?
• Only suggest cli and other packages, no new strong dependencies

Having a problem accessing the site:

Also, I could not pass up the chance to write the title for this issue 🤓

In a recent twitter-storm about project-based thinking and file paths, a really good point was raised that I too have felt (sorry, I can't find the tweet now).

RStudio, for example, does tab completion on filenames within a Project, which is very handy.

But then here::here() expects the path parts separated out into a character vector.

Is there a way to have our cake and eat it too? Could the relative paths produced by RStudio be acceptable to here::here()? Or could there be a helper function or add-in that converts these easy-to-get paths into the proper form?

There seems to be an issue where here:: loses functionality inside any level of knitr child document. I have created an MWE (below) which appears to successfully reproduce this issue.

Create the following project directory tree:

user@host:~/testing
$ tree
.
├── .git   # I created an empty .git directory
├── 0100.Rnw
├── 0110.Rnw
├── assets
│   └── 0111.Rnw
└── root.Rnw

where root.Rnw contains the following straight-forward knitr code:

\documentclass{article}
\begin{document}
<<'load-R-packages', echo=TRUE, results='markup', message=TRUE>>=
library(knitr)
knitr::opts_knit$set(
   #self.contained = FALSE, # TRUE/FALSE had no effect on this issue
   child.path = '')
knitr::opts_chunk$set(
   cache = FALSE,
   echo = TRUE,
   eval = TRUE,
   results = 'markup',
   message = FALSE)
library(here)
here::dr_here()
@

<<child='0100.Rnw', echo=F, results="hide">>=
@

\end{document}

and where each of the files 0100.Rnw and 0110.Rnw contain two simple chunks: the first containing here::dr_here() and the second using child to point at the next file. So root.Rnw -> 0100.Rnw -> 0110.Rnw -> assets/0111.Rnw. The final file, assets/0111.Rnw, is just one chunk containing here::dr_here().

The document was then compiled using knitr and pdflatex from the shell:

Rscript -e "library(knitr); library(methods); knit('root.Rnw')
pdflatex root.tex

This MWE successfully replicates the behaviour I'm seeing in my (much more complex) thesis document, namely that here::here() seems to cease working inside the child files (illustrated in this case by dr_here()).

I think the problem can be boiled down to why doesn't dr_here() produce any output when called from inside a knitr child document? All the child documents, irrespective of whether they live in the project root itself or in a sub-directory, simply produce no R output in the PDF. No errors or warnings either.

Can anyone reproduce this? And is this an intended effect? As far as I understand, child docs in knitr all share the same R environment as the parent, so why is here behaving differently in child documents?

I include a copy of the created PDF below (which includes extra rubrics for easier reading):

> sessionInfo()
R version 3.6.2 (2019-12-12)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.5 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1

locale:
 [1] LC_CTYPE=en_GB.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_GB.UTF-8        LC_COLLATE=en_GB.UTF-8    
 [5] LC_MONETARY=en_GB.UTF-8    LC_MESSAGES=en_GB.UTF-8   
 [7] LC_PAPER=en_GB.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
[1] compiler_3.6.2

For the sake of completeness, here's the contents of the child Rnw files I described above:

\section{First-level child Rnw of main document}
This is the first-level child. It lives inside the project root directory.
<<echo=TRUE, results="markup">>=
here::dr_here()
@

<<child='0110.Rnw', eval=TRUE>>=
@

\section{Second-level child document}
This is a child of a child Rnw. This file lives inside the project root directory.
<<echo=TRUE, results="markup">>=
here::dr_here()
@

<<child='assets/0111.Rnw', eval=TRUE>>=
@

\section{Third-level child document}
This is a third-level child document.
This file lives inside a sub-directory to the project root.
<<echo=TRUE, results="markup">>=
here::dr_here()
@

Is there anyway to override the directory here() picks? To me it seems like you can't, so if it's not your preferred directory you just have to restart your R session.

I started using here::here to make files more robust. If there are multiple nested functions using here::here I have to know whether my path is already an absolute path, moreover if I use here::here inside a function the user must not supply absolute paths. My workaround is having

if (startsWith(path, '/')) {path} else {here::here(path)}

but I wonder if this could be part of the {here} package itself.

(here is hard to reprex, but this issue is not related to that, if you apply here to a valid absolute path you will end up with a non existent path)

here::here("/Users")
#> [1] "/private/var/folders/rw/ky5hq6q95kd66vw7mpbsnx5w0000gp/T/RtmpfIF2tO//Users"

Created on 2019-04-15 by the reprex package (v0.2.0).

devtools::session_info()
#> ─ Session info ──────────────────────────────────────────────────────────
#>  setting  value                       
#>  version  R version 3.5.0 (2018-04-23)
#>  os       macOS Sierra 10.12.6        
#>  system   x86_64, darwin15.6.0        
#>  ui       X11                         
#>  language (EN)                        
#>  collate  en_US.UTF-8                 
#>  ctype    en_US.UTF-8                 
#>  tz       Europe/Budapest             
#>  date     2019-04-15                  
#> 
#> ─ Packages ──────────────────────────────────────────────────────────────
#>  package     * version date       lib source                     
#>  assertthat    0.2.0   2017-04-11 [1] CRAN (R 3.5.0)             
#>  backports     1.1.3   2018-12-14 [1] CRAN (R 3.5.0)             
#>  callr         3.1.1   2018-12-21 [1] CRAN (R 3.5.0)             
#>  cli           1.0.1   2018-09-25 [1] CRAN (R 3.5.0)             
#>  crayon        1.3.4   2017-09-16 [1] CRAN (R 3.5.0)             
#>  desc          1.2.0   2018-05-01 [1] CRAN (R 3.5.0)             
#>  devtools      2.0.1   2018-10-26 [1] CRAN (R 3.5.0)             
#>  digest        0.6.18  2018-10-10 [1] CRAN (R 3.5.0)             
#>  evaluate      0.13    2019-02-12 [1] CRAN (R 3.5.2)             
#>  fs            1.2.6   2018-08-23 [1] CRAN (R 3.5.0)             
#>  glue          1.3.0   2018-07-17 [1] CRAN (R 3.5.0)             
#>  here          0.1-11  2019-04-15 [1] Github (r-lib/here@d22ff63)
#>  highr         0.7     2018-06-09 [1] CRAN (R 3.5.0)             
#>  htmltools     0.3.6   2017-04-28 [1] CRAN (R 3.5.0)             
#>  knitr         1.21    2018-12-10 [1] CRAN (R 3.5.0)             
#>  magrittr      1.5     2014-11-22 [1] CRAN (R 3.5.0)             
#>  memoise       1.1.0   2017-04-21 [1] CRAN (R 3.5.0)             
#>  pkgbuild      1.0.2   2018-10-16 [1] CRAN (R 3.5.0)             
#>  pkgload       1.0.2   2018-10-29 [1] CRAN (R 3.5.0)             
#>  prettyunits   1.0.2   2015-07-13 [1] CRAN (R 3.5.0)             
#>  processx      3.2.1   2018-12-05 [1] CRAN (R 3.5.0)             
#>  ps            1.3.0   2018-12-21 [1] CRAN (R 3.5.0)             
#>  R6            2.4.0   2019-02-14 [1] CRAN (R 3.5.2)             
#>  Rcpp          1.0.1   2019-03-17 [1] CRAN (R 3.5.2)             
#>  remotes       2.0.2   2018-10-30 [1] CRAN (R 3.5.0)             
#>  rlang         0.3.1   2019-01-08 [1] CRAN (R 3.5.2)             
#>  rmarkdown     1.11    2018-12-08 [1] CRAN (R 3.5.0)             
#>  rprojroot     1.3-2   2018-01-03 [1] CRAN (R 3.5.0)             
#>  sessioninfo   1.1.1   2018-11-05 [1] CRAN (R 3.5.0)             
#>  stringi       1.3.1   2019-02-13 [1] CRAN (R 3.5.2)             
#>  stringr       1.4.0   2019-02-10 [1] CRAN (R 3.5.0)             
#>  testthat      2.0.1   2018-10-13 [1] CRAN (R 3.5.0)             
#>  usethis       1.4.0   2018-08-14 [1] CRAN (R 3.5.0)             
#>  withr         2.1.2   2018-03-15 [1] CRAN (R 3.5.0)             
#>  xfun          0.5     2019-02-20 [1] CRAN (R 3.5.2)             
#>  yaml          2.2.0   2018-07-25 [1] CRAN (R 3.5.0)             
#> 
#> [1] /Library/Frameworks/R.framework/Versions/3.5/Resources/library

Hey @krlmlr - I am not 100% sure this is a problem with here, but I thought I would start "here" and see what you thought. I apologize for this being long winded...

I have students use here at the top of R notebooks that they write individual assignments up in. Their notebooks are embedded in a folder structure that looks like this:

assignment/
   assignment.Rproj
   
   data/
      data.csv

   docs/
      assignment.Rmd
      assignment.nb.html

There is a common syntax they use at the top of each notebook to make sure that the root directory for their notebook is set to the directory with the .Rproj file, which looks like this:

knitr::opts_knit$set(root.dir = here::here())

You can see an example of how this works in this assignment replication. You'll notice that the example is similarly laid out, with a csv file in the data subdirectory and a notebook in the docs subdirectory.

In that specific assignment, I had a number of students get errors when they went to load data from the data subdirectory:

> riverData <- read_csv("data/MO_HYDRO_ImpairedRiversStreams.csv")
Error: 'MO_HYDRO_ImpairedRiversStreams.csv' does not exist in current working directory ('C:/Users/Owner/Documents/GitHub/DoeAssignments/Labs/Lab-02/docs')

or

damsRaw <- read.csv("data/MO_HYDRO_Dams.csv")
#> Warning in file(file, "rt"): cannot open file 'data/MO_HYDRO_Dams.csv': No
#> such file or directory
#> Error in file(file, "rt"): cannot open the connection

As you can see, the errors happen with both readr as well as the base R read.csv() function, so I am reasonably sure that the issue is not specific to the function that is being used to import data but rather something else. I also manually verified with both students that the folders existed where they should have and that there were no spelling errors in their code.

In both students' cases, they were using the "Run All Chunks Above" button to execute a number of chunks including that first setup chunk. I verified that this executed the setup code chunk with the root directory function shown above (you could see a record of it being run in the console). However, the notebook did not switch its root directory, and thus was trying to find the data/MO_HYDRO_ImpairedRiversStreams.csv within the docs subdirectory.

However, when we executed each chunk manually with the "Run Current Chunk" button, the root directory was reset and they were able to load the data without error.

The only commonality between the two students, other than the same folder structure and data source, is that they were both on Windows laptops.

My sense is that either here is not actually feeding the notebook the right file path when the code chunk gets executed as part of the "Run All Chunks Above" process or that the opts_knit$set(root.dir = here()) process is not actually setting what it gets from here. I'm not sure which of these is the answer, however.

Any thoughts you have on whether this is a bug with here or what else might be causing it would be very much appreciated! We have a workaround for now (executing code manually the first time) but it would be great to address this in a more sustainable way.

This may be a picky point, but the only way to use i_am() with a compound path is to provide the file separator. I understand that one of the goals of {here} is to abstract the file separator away from the user.

Could the ... argument in i_am() be implemented the same way as it is for here()?

I see from the i_am() documentation that ... is reserved for future use, could this be it?

Thanks!

I have been trying to use here() within a project where I am importing data from an online Research database.

I have then attempt to use here() within the saveRDS() function e.g.

saveRDS(mydfname, file= here("02_data", "mydfname.rda"))

This would ensure I have a local copy of the data for if I need to work on the project but I am offline.

When I execute the code my data import runs as expected, but the saveRDS function returns the following error

Error in here("02_data", "mydfname.rda") : unused arguments ("02_data", "mydfname.rda")

I have searched the issues listed here and online but have not found any other reports of this issue.

My work around is that I am having to input the file directory in full for saveRDS() but here is working for file calls using readRDS() and source()

I may be missing something simple so excuse my ignorance if that is the case.

I'm considering ditching the base_path parameter in all the usepackage functions and instead using here::here(). It would be nice if there was some easy way to temporary set the "here" directory somewhere else for testing.