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-boun...@r-project.org> 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 +0000
> From: luke-tier...@uiowa.edu
> To: Duncan Murdoch <murdoch.dun...@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.dun...@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@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-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.

Reply via email to