Re: [R] /usr/local/lib/R/site-library is not writable
I would actually go a step in the other direction: per project libraries. For example by adding a .Rprofile file to your project directory. This ensures that everybody working on a project uses the same version of the packages (even on different machines e.g. on shared folders). This can give issues when a new version of R arrives, but that is usually easy to solve. Either hard code the path to the old R-version or decide to update all packages in a project to the new R-version (and test that everything is still working ok). We have the most often used packages installed centrally on the server/network, so I actually usually end up with a mixture of central, personal and project libraries. Theory vs practice. HTH, Jan On 08-04-2021 02:58, Dirk Eddelbuettel wrote: Hi Gene, "It's complicated". (Not really, but listen for a sec...) We need to ship a default policy that makes sense for all / most situations. So - users cannot write into /usr/local/lib/R/site-library -- unless they are set up to, but adding them to the 'group' that owns that directory - root can (but ideally one should not run as root as one generally does not now what code you might get slipped in a tar.gz); but root can enable users - so we recommend letting (some or all) users write there by explicitly adding them to an appropriate group. Personally, I do not think personal libraries are a good idea on shared machines because you can end up with a different set of package (versions) than your colleague on the same machine. And or you running shiny from $HOME have different packages than shiny running as server. And on and on. Other people differ, and that is fine. If one wants personal libraries one can. I must have explained the reasoning and fixes a dozen times each on r-sig-debian (where you could have asked this too) and StackOverflow. At least the latter can be searched so look at this set: https://stackoverflow.com/search?q=user%3Ame+is%3Aanser+%2Fusr%2Flocal%2Flib%2FR%2Fsite-library Happy to take it offline too, and who knows, we even get to meet for a coffee one of these days. Hope this helps, Dirk __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] /usr/local/lib/R/site-library is not writable
Hi Gene, "It's complicated". (Not really, but listen for a sec...) We need to ship a default policy that makes sense for all / most situations. So - users cannot write into /usr/local/lib/R/site-library -- unless they are set up to, but adding them to the 'group' that owns that directory - root can (but ideally one should not run as root as one generally does not now what code you might get slipped in a tar.gz); but root can enable users - so we recommend letting (some or all) users write there by explicitly adding them to an appropriate group. Personally, I do not think personal libraries are a good idea on shared machines because you can end up with a different set of package (versions) than your colleague on the same machine. And or you running shiny from $HOME have different packages than shiny running as server. And on and on. Other people differ, and that is fine. If one wants personal libraries one can. I must have explained the reasoning and fixes a dozen times each on r-sig-debian (where you could have asked this too) and StackOverflow. At least the latter can be searched so look at this set: https://stackoverflow.com/search?q=user%3Ame+is%3Aanser+%2Fusr%2Flocal%2Flib%2FR%2Fsite-library Happy to take it offline too, and who knows, we even get to meet for a coffee one of these days. Hope this helps, Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] /usr/local/lib/R/site-library is not writable
1. Use a personal library. Mucking with the default library puts you at risk of
changing file permissions on your personal files inadvertently and making them
unusable by your normal user. Even if you did alter your user permissions so
you could mess with it without elevating privileges, POSIX is designed as a
multi-user system and the other users will generally not like having shared
packages changed without their knowledge.
2. The default library is where R goes looking if you don't have the desired
package in your personal package. It is normally updated only when the R
software is updated.
On April 7, 2021 12:40:04 PM PDT, Gene Leynes wrote:
>Hello R Community,
>
>I've been using R for a long time, and this is a question that still
>makes
>me think twice every single time I install R, which is more and more
>often .
>
>The first search hit is this StackOverflow question:
>https://stackoverflow.com/questions/32540919/library-is-not-writable
>
>The warning message hasn't changed over the years:
>
>install.packages("randomForest")
>Installing package into ‘/usr/local/lib/R/site-library’
>(as ‘lib’ is unspecified)
>Warning in install.packages :
> 'lib = "/usr/local/lib/R/site-library"' is not writable
>
>In this question they suggest using the personal library, which is what
>I
>end up doing as well, but some people suggest changing your group.
>This
>actually seems like the right answer to me, but others say they had
>problems when they changed groups, which also sounds about right.
>
>Can someone please tell me (or tell StackOverflow) the real best
>practice?
>
>I've gotten into some very thorny issues with installations that can't
>find
>any library when I deploy jobs using cron or other users, and it's hard
>to
>remember / figure out how to install (if missing) libraries in the
>script
>because it's hard to remember the mirror syntax.
>
>I know there's a packrat package, and I've invented some workarounds,
>but
>I normally just need two or three stable packages for a particular
>project.
>I'd bet that .libPaths would be implemented differently today, but
>maybe
>with the right library path none of that would be necessary to
>understand?
>
>My final simplified questions are:
>
> 1. What is the best practice to install libraries so that the current
> user (Linux) can always find them?
> 2. Why is the default library path not writable by default, should we
> change that?
>
>Hope everyone's doing well out there, and I hope to see some of you at
>conferences when things get back to normal.
>
>Thank you,
>
>Gene
>
> [[alternative HTML version deleted]]
>
>__
>R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>https://stat.ethz.ch/mailman/listinfo/r-help
>PLEASE do read the posting guide
>http://www.R-project.org/posting-guide.html
>and provide commented, minimal, self-contained, reproducible code.
--
Sent from my phone. Please excuse my brevity.
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Re: [R] /usr/local/lib/R/site-library is not writable
Hi Gene,
This is probably not best practice, but I install packages as root,
which allows me to write into the default library. The restriction on
non-root users being blocked from making changes to appications is
pretty standard.
Jim
On Thu, Apr 8, 2021 at 8:18 AM Gene Leynes wrote:
>
> Hello R Community,
>
> I've been using R for a long time, and this is a question that still makes
> me think twice every single time I install R, which is more and more often .
>
> The first search hit is this StackOverflow question:
> https://stackoverflow.com/questions/32540919/library-is-not-writable
>
> The warning message hasn't changed over the years:
>
> install.packages("randomForest")
> Installing package into ‘/usr/local/lib/R/site-library’
> (as ‘lib’ is unspecified)
> Warning in install.packages :
> 'lib = "/usr/local/lib/R/site-library"' is not writable
>
> In this question they suggest using the personal library, which is what I
> end up doing as well, but some people suggest changing your group. This
> actually seems like the right answer to me, but others say they had
> problems when they changed groups, which also sounds about right.
>
> Can someone please tell me (or tell StackOverflow) the real best practice?
>
> I've gotten into some very thorny issues with installations that can't find
> any library when I deploy jobs using cron or other users, and it's hard to
> remember / figure out how to install (if missing) libraries in the script
> because it's hard to remember the mirror syntax.
>
> I know there's a packrat package, and I've invented some workarounds, but
> I normally just need two or three stable packages for a particular project.
> I'd bet that .libPaths would be implemented differently today, but maybe
> with the right library path none of that would be necessary to understand?
>
> My final simplified questions are:
>
>1. What is the best practice to install libraries so that the current
>user (Linux) can always find them?
>2. Why is the default library path not writable by default, should we
>change that?
>
> Hope everyone's doing well out there, and I hope to see some of you at
> conferences when things get back to normal.
>
> Thank you,
>
> Gene
>
> [[alternative HTML version deleted]]
>
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
[R] /usr/local/lib/R/site-library is not writable
Hello R Community,
I've been using R for a long time, and this is a question that still makes
me think twice every single time I install R, which is more and more often .
The first search hit is this StackOverflow question:
https://stackoverflow.com/questions/32540919/library-is-not-writable
The warning message hasn't changed over the years:
install.packages("randomForest")
Installing package into ‘/usr/local/lib/R/site-library’
(as ‘lib’ is unspecified)
Warning in install.packages :
'lib = "/usr/local/lib/R/site-library"' is not writable
In this question they suggest using the personal library, which is what I
end up doing as well, but some people suggest changing your group. This
actually seems like the right answer to me, but others say they had
problems when they changed groups, which also sounds about right.
Can someone please tell me (or tell StackOverflow) the real best practice?
I've gotten into some very thorny issues with installations that can't find
any library when I deploy jobs using cron or other users, and it's hard to
remember / figure out how to install (if missing) libraries in the script
because it's hard to remember the mirror syntax.
I know there's a packrat package, and I've invented some workarounds, but
I normally just need two or three stable packages for a particular project.
I'd bet that .libPaths would be implemented differently today, but maybe
with the right library path none of that would be necessary to understand?
My final simplified questions are:
1. What is the best practice to install libraries so that the current
user (Linux) can always find them?
2. Why is the default library path not writable by default, should we
change that?
Hope everyone's doing well out there, and I hope to see some of you at
conferences when things get back to normal.
Thank you,
Gene
[[alternative HTML version deleted]]
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
