do not modify absolute paths

[czeildi]

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).

Session info

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

[lgaborini]

I was about to post the same issue.

This also breaks the possibility to use here (citing from the documentation) as a drop-in replacement to file.path.

1. file.path avoids pasting absolute paths (at least, on Windows)
2. file.path does not attempt at producing an absolute path, that's the job of normalizePath

library(here)

dir_wd_abs <- here()
dir_wd_abs
# "C:/Temp"

dir_subdir <- 'subdir'

here(dir_subdir)
# "C:/Temp/subdir"

file.path(dir_subdir)
# "subdir"

dir_subdir_abs <- here(dir_wd_abs, dir_subdir)
dir_subdir_abs
# "C:/Temp/C:/Temp/C:/Temp/subdir"

file.path(dir_wd_abs, dir_subdir)
# "C:/Temp/subdir"

[krlmlr]

Maybe relative paths, as suggested in #36, would be a solution?

[czeildi]

Thanks! I do not yet see how fs::path_rel or other {fs} functions would easily solve my problem. I can do a solution, for example fs::is_absolute_path is more robust than the above startsWith(path, '/') but I still need an if in my code.

To clarify what I'd like to achieve: I want my function to be able to accept both absolute paths and relative paths to the project root and return either absolute paths or relative paths relative to the working directory (so that they are safe to use in Rmd in sub folder or in tests for example.

I imagine something like the following:

# Users/ildi/project
# - a
#   - b.txt
# - c
#   - d.R

# in directory project/a
safe_here("a/b.txt")
# /Users/ildi/project/a/b.txt
safe_here("/Users/ildi/project/a/b.txt")
# /Users/ildi/project/a/b.txt

# in directory project
safe_here("a/b.txt")
# /Users/ildi/project/a/b.txt
safe_here("/Users/ildi/project/a/b.txt")
# /Users/ildi/project/a/b.txt

# OR

# in directory project/a
safe_path("a/b.txt")
# b.txt
safe_path("/Users/ildi/project/a/b.txt")
# b.txt

# in directory project/c
safe_path("a/b.txt")
# ../a/b.txt
safe_path("/Users/ildi/project/a/b.txt")
# ../a/b.txt

# in directory project
safe_path("a/b.txt")
# a/b.txt
safe_path("/Users/ildi/project/a/b.txt")
# a/b.txt

I am fine with closing this issue as it is an almost duplicate of #34.

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue and link to this old issue if necessary.