/usr/local/lib/R/site-library is not writable

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

/usr/local/lib/R/site-library is not writable

Gene Leynes-2
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]]

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: /usr/local/lib/R/site-library is not writable

Jim Lemon-4
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 <[hidden email]> 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]]
>
> ______________________________________________
> [hidden email] 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.

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: /usr/local/lib/R/site-library is not writable

Jeff Newmiller
In reply to this post by Gene Leynes-2
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 <[hidden email]> 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]]
>
>______________________________________________
>[hidden email] 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.

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: /usr/local/lib/R/site-library is not writable

Dirk Eddelbuettel

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 | [hidden email]

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: /usr/local/lib/R/site-library is not writable

Jan van der LAan-2

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
>

______________________________________________
[hidden email] 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.