Message-ID: <834406cc-a7a2-2cf7-86de-3dbfdd4a3ba4@gmail.com>
Date: 2021-02-02T21:37:23Z
From: Duncan Murdoch
Subject: [R-pkg-devel] Undeclared packages ... in Rd xrefs
In-Reply-To: <205cea6a-d9c8-15eb-e38a-80826c32ce80@beuth-hochschule.de>
On 02/02/2021 9:13 a.m., Ulrike Gr?mping wrote:
> Am 02.02.2021 um 02:38 schrieb Duncan Murdoch:
>> On 01/02/2021 5:03 p.m., Ulrike Gr?mping wrote:
>>> Dear package developeRs,
>>>
>>> under the Fedora clang checks, I find the note
>>>
>>> "Undeclared packages ?FrF2?, ?DoE.wrapper?, ?sfsmisc?, ?DoE.MIParray?,
>>> ?planor? in Rd xrefs"
>>>
>>> for my package DoE.base. I understand that package planor has been
>>> archived from CRAN; I don't understand what is wrong with the other
>>> xrefs; only the R-Devel Fedora clang flavor seems to complain, and I did
>>> not find an explanation in the section on cross references in Writing R
>>> Extensions. Can someone explain the meaning of this note?
>>
>> There's a line in the Writing R Extensions manual section 2.5
>> Cross-refernces for R-devel that says:
>>
>> "Packages referred to by these ?other forms? should be declared in the
>> DESCRIPTION file, in the ?Depends?, ?Imports?, ?Suggests? or
>> ?Enhances? fields."
>>
>> The other forms are the forms of links to other packages.? So
>> presumably you don't mention those packages in your DESCRIPTION file.
>> Generally that means they should be listed in Suggests, which doesn't
>> force them to be installed, but they will be installed during tests.
>> You might also argue they should be in Enhances, though that seems a
>> worse fit.
>>
>> Duncan Murdoch
>
>
> Thank you for the explanation! I will remove the xref to sfsmisc
> (because it does not make sense to suggest that package). The three
> other still available packages all depend on or import DoE.base. Thus,
> if I incorporate them in Suggests, I will create a circular dependence
> structure. Doesn't that create problems?
It creates small problems, not serious ones. You just need to make sure
that a version of your package is available when those packages are
installed for testing. So things need to happen in something like this
order on a totally new machine:
- install the "hard" dependencies for your package.
- install your package
- install the "soft" dependencies for your package.
I just discovered that the remotes::install_deps(dependencies = TRUE)
function can't currently do things in the right order, but
remotes::install_local(dependencies = TRUE) is fine. I didn't check the
base function install.packages(dependencies = TRUE).
Duncan Murdoch