[R] [External] Re: Building Packages. (fwd)
@vi@e@gross m@iii@g oii gm@ii@com
@vi@e@gross m@iii@g oii gm@ii@com
Thu Mar 21 17:30:48 CET 2024
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 <r-help-bounces using r-project.org> On Behalf Of Duncan Murdoch
Sent: Thursday, March 21, 2024 8:28 AM
To: luke-tierney using uiowa.edu; r-help using 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 +0000
> From: luke-tierney using uiowa.edu
> To: Duncan Murdoch <murdoch.duncan using gmail.com>
> 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, ...)
>>> <environment: 0x7f79e0019860>
>>>
>>> -pd
>>>
>>>> On 21 Mar 2024, at 09:58 , Duncan Murdoch <murdoch.duncan using gmail.com>
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, ...) <environment: 0x7fa7c72a6268>
>>>>> >>
>>>>> >> 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 using 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 using 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 using 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.
More information about the R-help
mailing list