R help - Jan 2020 - Which external functions are called in a package?

How can I find out which functions of my package A are called within
another package B that depends on, imports, or suggests package A ?
And more specifically, which functions in B are calling functions in A ?

I tried to utilize the *pkgapi* package, but get error messages like

    > map_package("./R/x86_64-pc-linux-gnu-library/3.6/cranlogs")

    Error: <callr_status_error: callr subprocess failed:
        invalid first argument>
    -->
    <callr_remote_error in mget(targets, envir = env,
        mode = "function", inherits = TRUE,  ...:
     invalid first argument>
     in process 22909

(1) What do these error messages mean?

(2) Are there easier ways to get this information?

Thanks in advance. --HW

On 03/01/2020 12:26 p.m., Hans W Borchers wrote:
> How can I find out which functions of my package A are called within
> another package B that depends on, imports, or suggests package A ?
> And more specifically, which functions in B are calling functions in A ?
> 
> I tried to utilize the *pkgapi* package, but get error messages like
> 
>      >
map_package("./R/x86_64-pc-linux-gnu-library/3.6/cranlogs")
> 
>      Error: <callr_status_error: callr subprocess failed:
>          invalid first argument>
>      -->
>      <callr_remote_error in mget(targets, envir = env,
>          mode = "function", inherits = TRUE,  ...:
>       invalid first argument>
>       in process 22909
> 
> (1) What do these error messages mean?
> 
> (2) Are there easier ways to get this information?
I'm not really familiar with pkgapi, but I believe the first argument is 
to the source directory for a package.  It looks as though you are 
pointing to the installed copy of it.

Duncan Murdoch

You are absolutely right. I forgot that there is a difference between
the unpacked and the installed directory of a package. The
documentation of the *pkgapi* package in development is quite scarce
and does not mention the details. Thanks for the tip.

--HW

PS: Still I would like to learn about other approaches for listing
external calls of a package. This must be a general problem for
package developers whose packages are depended on by many other CRAN
packages.


On Fri, 3 Jan 2020 at 20:19, Duncan Murdoch <murdoch.duncan at gmail.com>
wrote:
>
> I'm not really familiar with pkgapi, but I believe the first argument
is
> to the source directory for a package.  It looks as though you are
> pointing to the installed copy of it.
>
> Duncan Murdoch

If you are so lucky as to have this problem, perhaps you could take a look at
the reverse dependencies on your packages' CRAN web page.

On January 3, 2020 1:45:42 PM PST, Hans W Borchers <hwborchers at
gmail.com> wrote:
>You are absolutely right. I forgot that there is a difference between
>the unpacked and the installed directory of a package. The
>documentation of the *pkgapi* package in development is quite scarce
>and does not mention the details. Thanks for the tip.
>
>--HW
>
>PS: Still I would like to learn about other approaches for listing
>external calls of a package. This must be a general problem for
>package developers whose packages are depended on by many other CRAN
>packages.
>
>
>On Fri, 3 Jan 2020 at 20:19, Duncan Murdoch <murdoch.duncan at
gmail.com>
>wrote:
>>
>> I'm not really familiar with pkgapi, but I believe the first
argument
>is
>> to the source directory for a package.  It looks as though you are
>> pointing to the installed copy of it.
>>
>> Duncan Murdoch
>
>______________________________________________
>R-help at 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.

On 03/01/2020 4:45 p.m., Hans W Borchers wrote:
> You are absolutely right. I forgot that there is a difference between
> the unpacked and the installed directory of a package. The
> documentation of the *pkgapi* package in development is quite scarce
> and does not mention the details. Thanks for the tip.
> 
> --HW
> 
> PS: Still I would like to learn about other approaches for listing
> external calls of a package. This must be a general problem for
> package developers whose packages are depended on by many other CRAN
> packages.
>
I've never worried too much about that for my packages.  What matters is 
whether the changes I make cause trouble for other packages.  Knowing 
the reverse dependencies lets me test all the other packages after 
making changes, and if new problems come up, it's usually pretty obvious 
which of my functions were being used.

(I use some code I wrote for myself to run the tests with the old and 
new version of my package, but I believe there is similar code out there 
nowadays to do the comparison.  I'd look in devtools if I was looking 
for that.)

Duncan Murdoch