packrat does not run on a window's networked drive

[mbanghart]

The following warning is produced by the call to packrat::init()

Warning message: cannot set reparse point 'U:/packrat5/packrat/lib-R/base', reason 'Access is denied'

the warning comes from a call to Sys.junction(). Sys.junction() does not support window's networked drives.

The following email message is from the R-Devel list.

Unfortunately, junctions cannot link to a network drive, they only can link directories on the same computer (possibly on different local volumes). This is a limitation imposed by Windows. I have updated the documentation for Sys.junction in R-devel accordingly.

Network drives are an integral part of system. Can packrat be updated to run properly on a windows network drive? Mark

[eringrand]

Has there been any update on this issue?

[mbanghart]

I have not heard of any update on this issue.

[kevinushey]

In theory Packrat should be able to recover in this case. Packrat attempts to use junction points to re-map the R library paths into a local private folder, with some extra checks to ensure that user-installed packages that might've ended up in the system library are screened out.

When that junction attempt fails, Packrat should just 'do nothing' and keep using the original library paths.

I've pushed a potential fix to Packrat -- can you try testing with:

devtools::install_github("rstudio/packrat")

If it still fails, can you please supply me the full output of the packrat::init() call?

[mbanghart]

Kevin,

This is the output from the packrat::init().

Mark

packrat::init() Initializing packrat project in directory:

• "U:/packrat7" Adding these packages to packrat: _ packrat 0.4.9-6 Fetching sources for packrat (0.4.9-6) ... OK (GitHub) Snapshot written to "U:/packrat7/packrat/packrat.lock" Installing packrat (0.4.9-6) ... OK (built source) Initialization complete! Warning message: In Sys.junction(from, to) : cannot set reparse point 'U:/packrat7/packrat/lib-R/x86_64-w64-mingw32/3.4.3/base', reason 'Access is denied' Restarting R session... [1] "Finished loading Rprofile.site" Warning message: In Sys.junction(from, to) : cannot set reparse point 'U:/packrat7/packrat/lib-R/x86_64-w64-mingw32/3.4.3/base', reason 'Access is denied'

---

From: Kevin Ushey notifications@github.com Sent: Wednesday, June 13, 2018 2:11:59 PM To: rstudio/packrat Cc: MARK BANGHART; Author Subject: Re: [rstudio/packrat] packrat does not run on a window's networked drive (#452)

In theory Packrat should be able to recover in this case. Packrat attempts to use junction points to re-map the R library paths into a local private folder, with some extra checks to ensure that user-installed packages that might've ended up in the system library are screened out.

When that junction attempt fails, Packrat should just 'do nothing' and keep using the original library paths.

I've pushed a potential fix to Packrat -- can you try testing with:

devtools::install_github("rstudio/packrat")

If it still fails, can you please supply me the full output of the packrat::init() call?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/rstudio/packrat/issues/452#issuecomment-397052658, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGb_T1BgdwkvhO1DyDe4sFcO_9bIUOgMks5t8WP_gaJpZM4R-eSa.

[kevinushey]

Thanks -- it sounds like even though the warnings were emitted, Packrat did successfully initialize and restart?

Just to confirm what is the output of .libPaths() in that session after initialization as well?

[mbanghart]

Kevin,

Here is the output from .libPaths().

Mark

.libPaths() [1] "U:/packrat7/packrat/lib/x86_64-w64-mingw32/3.4.3" [2] "U:/packrat7/packrat/lib-ext/x86_64-w64-mingw32/3.4.3" [3] "C:/Program Files/R/R-3.4.3/library"

---

From: Kevin Ushey notifications@github.com Sent: Thursday, June 14, 2018 12:49:37 PM To: rstudio/packrat Cc: MARK BANGHART; Author Subject: Re: [rstudio/packrat] packrat does not run on a window's networked drive (#452)

Thanks -- it sounds like even though the warnings were emitted, Packrat did successfully initialize and restart?

Just to confirm what is the output of .libPaths() in that session after initialization as well?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/rstudio/packrat/issues/452#issuecomment-397381645, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGb_T1v_Y-dTdMY6ZrmEvVgYOYDXb7uNks5t8qIxgaJpZM4R-eSa.

[kevinushey]

Thanks. Given that, I would expect that Packrat would work without issue on your machine, despite the warnings. We might consider either suppressing or augmenting the warning message to be a bit clearer.

[mbanghart]

Kevin,

Some change to the warning would be very helpful for us. We are a research institute and code that produces warnings is considered problematic.

What specifically is the warning message letting us know?

Mark

---

From: Kevin Ushey notifications@github.com Sent: Thursday, June 14, 2018 1:36:14 PM To: rstudio/packrat Cc: MARK BANGHART; Author Subject: Re: [rstudio/packrat] packrat does not run on a window's networked drive (#452)

Thanks. Given that, I would expect that Packrat would work without issue on your machine, despite the warnings. We might consider either suppressing or augmenting the warning message to be a bit clearer.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/rstudio/packrat/issues/452#issuecomment-397396458, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGb_TzUfhyqVSBZ0auh9j0jfICtTvlyMks5t8q0egaJpZM4R-eSa.

[kevinushey]

The warning is basically stating that Packrat tried to link your R system packages into a local, private library folder within the project, but that attempt failed. This is done to improve encapsulation, for cases where the user has (inadvertently?) installed R packages into the system library. When that fails, there is in general no adverse affect to the user, except the potential for loss of that intended encapsulation.

[mbanghart]

Kevin,

If I understand what you sent, the warning is telling you that you might be at risk for not including all packages that you use. Is there a way to fix packrat so that this is not an issue?

Mark

---

From: Kevin Ushey notifications@github.com Sent: Thursday, June 14, 2018 2:03:39 PM To: rstudio/packrat Cc: MARK BANGHART; Author Subject: Re: [rstudio/packrat] packrat does not run on a window's networked drive (#452)

The warning is basically stating that Packrat tried to link your R system packages into a local, private library folder within the project, but that attempt failed. This is done to improve encapsulation, for cases where the user has (inadvertently?) installed R packages into the system library. When that fails, there is in general no adverse affect to the user, except the potential for loss of that intended encapsulation.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/rstudio/packrat/issues/452#issuecomment-397404579, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGb_T5rQuFJj0WlxmoN7k2Fod7jCPQtgks5t8rOLgaJpZM4R-eSa.

[kevinushey]

I guess that depends. Did you intentionally install extra packages into the system library for your R installation? Or are those usually installed into a user library path?

What is the output of list.files(.Library)?

[mbanghart]

Kevin,

I am one of many users on our network drives. I need to make sure they are going to be supported.

The output from list.files(.Library) from my RStudio session is.

Mark

list.files(.Library) [1] "alr4" "assertthat" [3] "backports" "base" [5] "base64enc" "bayesplot" [7] "bdsmatrix" "BH" [9] "bindr" "bindrcpp" [11] "bitops" "boot" [13] "BradleyTerry2" "brew" [15] "brglm" "broom" [17] "callr" "car" [19] "carData" "caret" [21] "caTools" "cellranger" [23] "class" "cli" [25] "clipr" "cluster" [27] "coda" "codetools" [29] "coin" "colorspace" [31] "colourpicker" "combinat" [33] "commonmark" "compiler" [35] "corpcor" "covr" [37] "coxme" "crayon" [39] "crosstalk" "Cubist" [41] "curl" "CVST" [43] "datasets" "DBI" [45] "dbplyr" "ddalpha" [47] "deldir" "DEoptimR" [49] "desc" "devtools" [51] "dichromat" "digest" [53] "dimRed" "dotCall64" [55] "dplyr" "DRR" [57] "DT" "dygraphs" [59] "e1071" "earth" [61] "effects" "ellipse" [63] "estimability" "evaluate" [65] "expm" "faraway" [67] "fastICA" "feather" [69] "forcats" "foreach" [71] "foreign" "Formula" [73] "gam" "gbm" [75] "gdata" "getPass" [77] "ggplot2" "git2r" [79] "glmnet" "glue" [81] "gmailr" "gmodels" [83] "gower" "gplots" [85] "graphics" "grDevices" [87] "grid" "gridExtra" [89] "gtable" "gtools" [91] "haven" "highr" [93] "hms" "htmltools" [95] "htmlwidgets" "httpuv" [97] "httr" "hunspell" [99] "ibdreg" "igraph" [101] "inline" "ipred" [103] "irlba" "ISwR" [105] "iterators" "jsonlite" [107] "kernlab" "KernSmooth" [109] "klaR" "knitr" [111] "labeling" "lars" [113] "lattice" "lava" [115] "lazyeval" "leaps" [117] "LearnBayes" "lintr" [119] "lme4" "lmtest" [121] "loo" "lsmeans" [123] "lubridate" "magrittr" [125] "markdown" "MASS" [127] "Matrix" "MatrixModels" [129] "matrixStats" "maxLik" [131] "mda" "memoise" [133] "methods" "mgcv" [135] "mime" "miniUI" [137] "minqa" "miscTools" [139] "mlbench" "MLmetrics" [141] "mnormt" "mockery" [143] "ModelMetrics" "modelr" [145] "modeltools" "multcomp" [147] "munsell" "mvtnorm" [149] "nlme" "nloptr" [151] "nnet" "numDeriv" [153] "openssl" "packrat" [155] "pamr" "parallel" [157] "party" "pbkrtest" [159] "pillar" "pkgconfig" [161] "PKI" "plm" [163] "plogr" "plotmo" [165] "plotrix" "pls" [167] "plyr" "praise" [169] "pROC" "prodlim" [171] "profileModel" "proxy" [173] "psych" "purrr" [175] "quantreg" "qvcalc" [177] "R6" "randomForest" [179] "RANN" "RColorBrewer" [181] "Rcpp" "RcppEigen" [183] "RcppRoll" "RCurl" [185] "readr" "readxl" [187] "recipes" "rematch" [189] "reprex" "reshape2" [191] "rex" "rgl" [193] "RJSONIO" "rlang" [195] "RLRsim" "rmarkdown" [197] "robustbase" "ROCR" [199] "roxygen2" "rpart" [201] "rprojroot" "rsconnect" [203] "rstan" "rstantools" [205] "rstudioapi" "RUnit" [207] "rversions" "rvest" [209] "sandwich" "scales" [211] "selectr" "sfsmisc" [213] "shiny" "shinyjs" [215] "shinystan" "shinythemes" [217] "sourcetools" "sp" [219] "spam" "SparseM" [221] "spatial" "spData" [223] "spdep" "sphet" [225] "splines" "splm" [227] "spls" "SQUAREM" [229] "StanHeaders" "stats" [231] "stats4" "stringdist" [233] "stringi" "stringr" [235] "strucchange" "subselect" [237] "superpc" "survey" [239] "survival" "tcltk" [241] "TeachingDemos" "testthat" [243] "TH.data" "threejs" [245] "tibble" "tidyr" [247] "tidyselect" "tidyverse" [249] "timeDate" "tools" [251] "translations" "tufte" [253] "utf8" "utils" [255] "viridisLite" "whisker" [257] "withr" "xml2" [259] "xtable" "xts" [261] "yaml" "zoo"

---

From: Kevin Ushey notifications@github.com Sent: Thursday, June 14, 2018 2:13:37 PM To: rstudio/packrat Cc: MARK BANGHART; Author Subject: Re: [rstudio/packrat] packrat does not run on a window's networked drive (#452)

I guess that depends. Did you intentionally install extra packages into the system library for your R installation? Or are those usually installed into a user library path?

What is the output of list.files(.Library)?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/rstudio/packrat/issues/452#issuecomment-397407254, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGb_T5wsr-t4vso7wpDPsFjpC0lN7He3ks5t8rXhgaJpZM4R-eSa.

[kevinushey]

Thanks for the response. And so you want each user to have access to these packages installed in the system library? (Note that Packrat would by default attempt to ensure that these extra packages are not available, under the assumption that users would install their own copies into their own project's private library)

[kevinushey]

FWIW in your configuration it sounds like you'll have the desired effect -- all of those system packages will be available for all users.

[mbanghart]

Kevin,

I am new to packrat so I may be missing something. My apologies in advance if I have.

We have a number of users who use packages out of a system library (so they are not replicated by each user.) Some of our user are now looking to packrat to enhance the reproducibility of their research. The thought was that packrat would encapsulate what is needed by the user.

I think I you are saying that the user would need to manually install the packages in their private library. If that is the case, why is there a warning? Mark

---

From: Kevin Ushey notifications@github.com Sent: Thursday, June 14, 2018 2:22:21 PM To: rstudio/packrat Cc: MARK BANGHART; Author Subject: Re: [rstudio/packrat] packrat does not run on a window's networked drive (#452)

Thanks for the response. And so you want each user to have access to these packages installed in the system library? (Note that Packrat would by default attempt to ensure that these extra packages are not available, under the assumption that users would install their own copies into their own project's private library)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/rstudio/packrat/issues/452#issuecomment-397409713, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGb_Tw6LniOooFcS4c8LOLFgLBYOk3Fvks5t8rftgaJpZM4R-eSa.

[kevinushey]

Here's what's going on.

1. On initialization, Packrat attempts to create its own facade of system-installed packages. These are specifically the 'base' R packages, not user-installed packages.

2. This is done by attempting to create junction points, one for each package. That is, for the package 'base', Packrat tries to create a junction point from the system library, into its own private library, and then use that library instead.

3. If that junction attempt fails, then Packrat will give up on that attempted encapsulation and just use the system library as-is.

By default, Packrat attempts you to shield you from user-installed packages in the system library, and this is by design. When that fails (as it seems to be in your case) a warning is emitted, and the system library is used as-is.

Ironically, it sounds like the failure here will actually get you the behavior you desire (users now have access to all packages in the system library) and so you will actually be in better shape here.

All that said, Packrat should probably provide an option to configure whether this system-library encapsulation is done or not.

[mbanghart]

Kevin,

Thanks for that excellent explanation.

I think we want the designed default behavior of packrat. That is we want most user, who are not using packrat, to use the system packages. But a user who enables packrat in a project to have packrat encapsulate any of the system installed packages. This would allow complete reproducibility for our users who need this.

I was told that packrat is using a feature that is not supported for windows networked drives. So this should be failing for anyone using windows networked drives. If that is the case, can the packrat package use a method to encapsulate the packages that works for windows network drives?

Mark

---

From: Kevin Ushey notifications@github.com Sent: Thursday, June 14, 2018 2:35:21 PM To: rstudio/packrat Cc: MARK BANGHART; Author Subject: Re: [rstudio/packrat] packrat does not run on a window's networked drive (#452)

Here's what's going on.

1. On initialization, Packrat attempts to create its own facade of system-installed packages. These are specifically the 'base' R packages, not user-installed packages.

2. This is done by attempting to create junction points, one for each package. That is, for the package 'base', Packrat tries to create a junction point from the system library, into its own private library, and then use that library instead.

3. If that junction attempt fails, then Packrat will give up on that attempted encapsulation and just use the system library as-is.

By default, Packrat attempts you to shield you from user-installed packages in the system library, and this is by design. When that fails (as it seems to be in your case) a warning is emitted, and the system library is used as-is.

Ironically, it sounds like the failure here will actually get you the behavior you desire (users now have access to all packages in the system library) and so you will actually be in better shape here.

All that said, Packrat should probably provide an option to configure whether this system-library encapsulation is done or not.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/rstudio/packrat/issues/452#issuecomment-397413238, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGb_T_SldDhsbnQ6VtmDayRklod2G-sZks5t8rr5gaJpZM4R-eSa.

[hack-r]

I also have this issue. So, is there any solution for using packrat on a network drive?