Re: [R] [External] Re: Building Packages. (fwd)
Thank you Duncan, you explained quite a bit. I am unclear how this change causes the problem the OP mentioned. It is an example of people using a clever trick to get what they think they want that could be avoided if the original program provided a hook. Of course the hook could be used more maliciously by others. -Original Message- From: R-help On Behalf Of Duncan Murdoch Sent: Thursday, March 21, 2024 8:28 AM To: luke-tier...@uiowa.edu; r-help@r-project.org Subject: Re: [R] [External] Re: Building Packages. (fwd) If you are wondering why RStudio did this, you can see their substitute function using (parent.env(environment(install.packages)))$hook They appear to do these things: - Allow package installation to be disabled. - Check if a package to be installed is already loaded, so that RStudio can restart R for the install. - Add Rtools to the PATH if necessary. - Trigger an event to say that something is about to be changed about the installed packages, presumably so that they can mark a cached list of installed packages as stale. - Call the original function. I think all of these things could be done if install.packages() called a hook at the start, as library() does (via attachNamespace()) when a package is attached. It might be that putting the wrapper code into tools:rstudio would cause confusion for users when there were two objects of the same name on the search list, though I don't see how. Duncan Murdoch On 21/03/2024 7:44 a.m., luke-tierney--- via R-help wrote: > [forgot to copy to R-help so re-sending] > > -- Forwarded message -- > Date: Thu, 21 Mar 2024 11:41:52 + > From: luke-tier...@uiowa.edu > To: Duncan Murdoch > Subject: Re: [External] Re: [R] Building Packages. > > At least on my installed version (which tells me it is out of date) > they appear to just be modifying the "package:utils" parent frame of > the global search path. > > There seem to be a few others: > > checkUtilsFun <- function(n) > identical(get(n, "package:utils"), get(n, getNamespace("utils"))) > names(which(! sapply(ls("package:utils", all = TRUE), checkUtilsFun))) > ## [1] "bug.report" "file.edit""help.request" ## [4] "history" > "install.packages" "remove.packages" ## [7] "View" > > I don't know why they don't put these overrides in the tools:rstudio frame. > At least that would make them more visible. > > You can fix all of these with something like > > local({ > up <- match("package:utils", search()) > detach("package:utils") > library(utils, pos = up) > }) > > or just install.packages with > > local({ > up <- match("package:utils", search()) > unlockBinding("install.packages", pos.to.env(up)) > assign("install.packages", utils::install.packages, "package:utils") > lockBinding("install.packages", pos.to.env(up)) > }) > > Best, > > luke > > On Thu, 21 Mar 2024, Duncan Murdoch wrote: > >> Yes, you're right. The version found in the search list entry for >> "package:utils" is the RStudio one; the ones found with two or three colons >> are the original. >> >> Duncan Murdoch >> >> On 21/03/2024 5:48 a.m., peter dalgaard wrote: >>> Um, what's with the triple colon? At least on my install, double seems to >>> suffice: >>> >>>> identical(utils:::install.packages, utils::install.packages) >>> [1] TRUE >>>> install.packages >>> function (...) >>> .rs.callAs(name, hook, original, ...) >>> >>> >>> -pd >>> >>>> On 21 Mar 2024, at 09:58 , Duncan Murdoch wrote: >>>> >>>> The good news for Jorgen (who may not be reading this thread any more) is >>>> that one can still be sure of getting the original install.packages() by >>>> using >>>> >>>> utils:::install.packages( ... ) >>>> >>>> with *three* colons, to get the internal (namespace) version of the >>>> function. >>>> >>>> Duncan Murdoch >>>> >>>> >>>> On 21/03/2024 4:31 a.m., Martin Maechler wrote: >>>>>>>>>> "Duncan Murdoch on Wed, 20 Mar 2024 13:20:12 -0400 writes: >>>>> > On 20/03/2024 1:07 p.m., Duncan Murdoch wrote: >>>>> >> On 20/03/2024 12:37 p.m., Ben Bolker wrote: >>>>> >>> Ivan, can you give more detail
Re: [R] [External] Re: Building Packages. (fwd)
If you are wondering why RStudio did this, you can see their substitute function using (parent.env(environment(install.packages)))$hook They appear to do these things: - Allow package installation to be disabled. - Check if a package to be installed is already loaded, so that RStudio can restart R for the install. - Add Rtools to the PATH if necessary. - Trigger an event to say that something is about to be changed about the installed packages, presumably so that they can mark a cached list of installed packages as stale. - Call the original function. I think all of these things could be done if install.packages() called a hook at the start, as library() does (via attachNamespace()) when a package is attached. It might be that putting the wrapper code into tools:rstudio would cause confusion for users when there were two objects of the same name on the search list, though I don't see how. Duncan Murdoch On 21/03/2024 7:44 a.m., luke-tierney--- via R-help wrote: [forgot to copy to R-help so re-sending] -- Forwarded message -- Date: Thu, 21 Mar 2024 11:41:52 + From: luke-tier...@uiowa.edu To: Duncan Murdoch Subject: Re: [External] Re: [R] Building Packages. At least on my installed version (which tells me it is out of date) they appear to just be modifying the "package:utils" parent frame of the global search path. There seem to be a few others: checkUtilsFun <- function(n) identical(get(n, "package:utils"), get(n, getNamespace("utils"))) names(which(! sapply(ls("package:utils", all = TRUE), checkUtilsFun))) ## [1] "bug.report" "file.edit""help.request" ## [4] "history" "install.packages" "remove.packages" ## [7] "View" I don't know why they don't put these overrides in the tools:rstudio frame. At least that would make them more visible. You can fix all of these with something like local({ up <- match("package:utils", search()) detach("package:utils") library(utils, pos = up) }) or just install.packages with local({ up <- match("package:utils", search()) unlockBinding("install.packages", pos.to.env(up)) assign("install.packages", utils::install.packages, "package:utils") lockBinding("install.packages", pos.to.env(up)) }) Best, luke On Thu, 21 Mar 2024, Duncan Murdoch wrote: Yes, you're right. The version found in the search list entry for "package:utils" is the RStudio one; the ones found with two or three colons are the original. Duncan Murdoch On 21/03/2024 5:48 a.m., peter dalgaard wrote: Um, what's with the triple colon? At least on my install, double seems to suffice: identical(utils:::install.packages, utils::install.packages) [1] TRUE install.packages function (...) .rs.callAs(name, hook, original, ...) -pd On 21 Mar 2024, at 09:58 , Duncan Murdoch wrote: The good news for Jorgen (who may not be reading this thread any more) is that one can still be sure of getting the original install.packages() by using utils:::install.packages( ... ) with *three* colons, to get the internal (namespace) version of the function. Duncan Murdoch On 21/03/2024 4:31 a.m., Martin Maechler wrote: "Duncan Murdoch on Wed, 20 Mar 2024 13:20:12 -0400 writes: > On 20/03/2024 1:07 p.m., Duncan Murdoch wrote: >> On 20/03/2024 12:37 p.m., Ben Bolker wrote: >>> Ivan, can you give more detail on this? I've heard this >>> issue mentioned, but when I open RStudio and run >>> find("install.packages") it returns >>> "utils::install.packages", and running dump() from >>> within RStudio console and from an external "R >>> --vanilla" gives identical results. >>> >>> I thought at one point this might only refer to the GUI >>> package-installation interface, but you seem to be >>> saying it's the install.packages() function as well. >>> >>> Running an up-to-date RStudio on Linux, FWIW -- maybe >>> weirdness only happens on other OSs? >> >> On MacOS, I see this: >> >> > install.packages function (...) .rs.callAs(name, hook, >> original, ...) >> >> I get the same results as you from find(). I'm not sure >> what RStudio is doing to give a different value for the >> function than what find() sees. > Turns out that RStudio replaces the install.packages > object in the utils package. > Duncan Murdoch Yes, and this has been the case for several years now, and I have mentioned this several times, too (though some of it possibly not in a public R-* mailing list). And yes, that they modify the package environment as.environment("package:utils") but leave the namespace asNamespace("utils") unchanged, makes it harder to see what's going on (but also has less severe consequences; if they kept to the otherwise universal *rule* that the namespace and package must have the same objects apart from those only in the namespace,
Re: [R] [External] Re: Building Packages. (fwd)
[forgot to copy to R-help so re-sending] -- Forwarded message -- Date: Thu, 21 Mar 2024 11:41:52 + From: luke-tier...@uiowa.edu To: Duncan Murdoch Subject: Re: [External] Re: [R] Building Packages. At least on my installed version (which tells me it is out of date) they appear to just be modifying the "package:utils" parent frame of the global search path. There seem to be a few others: checkUtilsFun <- function(n) identical(get(n, "package:utils"), get(n, getNamespace("utils"))) names(which(! sapply(ls("package:utils", all = TRUE), checkUtilsFun))) ## [1] "bug.report" "file.edit""help.request" ## [4] "history" "install.packages" "remove.packages" ## [7] "View" I don't know why they don't put these overrides in the tools:rstudio frame. At least that would make them more visible. You can fix all of these with something like local({ up <- match("package:utils", search()) detach("package:utils") library(utils, pos = up) }) or just install.packages with local({ up <- match("package:utils", search()) unlockBinding("install.packages", pos.to.env(up)) assign("install.packages", utils::install.packages, "package:utils") lockBinding("install.packages", pos.to.env(up)) }) Best, luke On Thu, 21 Mar 2024, Duncan Murdoch wrote: Yes, you're right. The version found in the search list entry for "package:utils" is the RStudio one; the ones found with two or three colons are the original. Duncan Murdoch On 21/03/2024 5:48 a.m., peter dalgaard wrote: Um, what's with the triple colon? At least on my install, double seems to suffice: identical(utils:::install.packages, utils::install.packages) [1] TRUE install.packages function (...) .rs.callAs(name, hook, original, ...) -pd On 21 Mar 2024, at 09:58 , Duncan Murdoch wrote: The good news for Jorgen (who may not be reading this thread any more) is that one can still be sure of getting the original install.packages() by using utils:::install.packages( ... ) with *three* colons, to get the internal (namespace) version of the function. Duncan Murdoch On 21/03/2024 4:31 a.m., Martin Maechler wrote: "Duncan Murdoch on Wed, 20 Mar 2024 13:20:12 -0400 writes: > On 20/03/2024 1:07 p.m., Duncan Murdoch wrote: >> On 20/03/2024 12:37 p.m., Ben Bolker wrote: >>> Ivan, can you give more detail on this? I've heard this >>> issue mentioned, but when I open RStudio and run >>> find("install.packages") it returns >>> "utils::install.packages", and running dump() from >>> within RStudio console and from an external "R >>> --vanilla" gives identical results. >>> >>> I thought at one point this might only refer to the GUI >>> package-installation interface, but you seem to be >>> saying it's the install.packages() function as well. >>> >>> Running an up-to-date RStudio on Linux, FWIW -- maybe >>> weirdness only happens on other OSs? >> >> On MacOS, I see this: >> >> > install.packages function (...) .rs.callAs(name, hook, >> original, ...) >> >> I get the same results as you from find(). I'm not sure >> what RStudio is doing to give a different value for the >> function than what find() sees. > Turns out that RStudio replaces the install.packages > object in the utils package. > Duncan Murdoch Yes, and this has been the case for several years now, and I have mentioned this several times, too (though some of it possibly not in a public R-* mailing list). And yes, that they modify the package environment as.environment("package:utils") but leave the namespace asNamespace("utils") unchanged, makes it harder to see what's going on (but also has less severe consequences; if they kept to the otherwise universal *rule* that the namespace and package must have the same objects apart from those only in the namespace, people would not even have access to R's true install.packages() but only see the RStudio fake^Hsubstitute.. We are still not happy with their decision. Also help(install.packages) goes to R's documentation of R's install.packages, so there's even more misleading of useRs. Martin __ 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. -- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Depart