Redefine proj_path_prep()

[jennybc]

Reconsider @jimhester's proposal from #479

Define proj_path_prep() as fs::path_abs(fs::path_expand()) instead of fs::path_real().

I think, in general, there is less path agony on Windows this way (will come back with concrete examples).

The new agony will be that rprojroot calls normalizePath(), so this issue is really to investigate how hard it would be to finesse that.

[jennybc]

This is a mess:

> library(usethis)
> proj_get()
✔ Setting active project to '//vmware-host/Shared Folders/win10/frommacos'
//vmware-host/Shared Folders/win10/frommacos
> proj_sitrep()
*   working_directory: 'Z:/win10/frommacos'
* active_usethis_proj: '//vmware-host/Shared Folders/win10/frommacos'
* active_rstudio_proj: 'Z:/win10/frommacos'
● Your working directory is not the same as the active usethis project.
  Set working directory to the project: `setwd(proj_get())`
  Set project to working directory:     `proj_set(getwd())`
● Your active RStudio Project is not the same as the active usethis project.
  Set usethis project to RStudio Project: `proj_set(rstudioapi::getActiveProject())`
  Restart RStudio in the usethis project: `rstudioapi::openProject(proj_get())`
  Open the usethis project in a new instance of RStudio: `proj_activate(proj_get())`

I am able to create almost all possible combinations of these 3 paths being Z:/ or UNC style. So perhaps the sitrep function itself should become aware of that? But, in general, making Z:/ style the default seems preferable to me.

[jennybc]

Various fs functions struggle more with UNC paths than drive paths:

> library(usethis)
> create_project("Z:/win10/jkl")
✔ Creating 'Z:/win10/jkl/'
✔ Setting active project to '//vmware-host/Shared Folders/win10/jkl'
 Error: [ENOENT] Failed to make directory '//vmware-host/Shared Folders': no such file or directory ✔ Setting active project to '<no active project>'
> fs::dir_create("Z:/win10/jkl")

It seems I would explore fewer fs edge cases if I stuck with drive or DOS paths.

[nalsalam]

This is a mess:

> library(usethis)
> proj_get()
✔ Setting active project to '//vmware-host/Shared Folders/win10/frommacos'
//vmware-host/Shared Folders/win10/frommacos
> proj_sitrep()
*   working_directory: 'Z:/win10/frommacos'
* active_usethis_proj: '//vmware-host/Shared Folders/win10/frommacos'
* active_rstudio_proj: 'Z:/win10/frommacos'
● Your working directory is not the same as the active usethis project.
  Set working directory to the project: `setwd(proj_get())`
  Set project to working directory:     `proj_set(getwd())`
● Your active RStudio Project is not the same as the active usethis project.
  Set usethis project to RStudio Project: `proj_set(rstudioapi::getActiveProject())`
  Restart RStudio in the usethis project: `rstudioapi::openProject(proj_get())`
  Open the usethis project in a new instance of RStudio: `proj_activate(proj_get())`

I am able to create almost all possible combinations of these 3 paths being Z:/ or UNC style. So perhaps the sitrep function itself should become aware of that? But, in general, making Z:/ style the default seems preferable to me.

Yes, this is a problem for me. I created an issue in fs (https://github.com/r-lib/fs/issues/402) but maybe it is more properly here.

[chriscarrollsmith]

I also encountered this problem on Windows.

...
ℹ Your working directory is not the same as the active RStudio Project. 
☐ Set working directory to the Project:
  `setwd(rstudioapi::getActiveProject())`.
...
> setwd(rstudioapi::getActiveProject())
Error in setwd(rstudioapi::getActiveProject()) : 
  cannot change working directory
> rstudioapi::getActiveProject()
[1] "/c:/Users/chris/Software/R/Projects/countryaggr"
> getwd()
[1] "C:/Users/chris/Software/R/Projects/countryaggr"