These recently introduced 'R CMD check' WARNINGs were disabled again in R-devel on July 8, 2020:
r78793: https://github.com/wch/r-source/commit/ccd903e47ab42e1c181396256aea56454a2e70c9 r78794: https://github.com/wch/r-source/commit/b70f90ae11dd516c1c954ed15eb5a7c2a304b37f This is because there's a plan to add support for what we're all asking for in one way or the other. That's all I know. /Henrik On Mon, Aug 10, 2020 at 8:51 AM John Mount <jmo...@win-vector.com> wrote: > > To all: I'd like to apologize for my negative tone and imprecision in my > points. Thanks for the discussion and the effort you put into these systems. > > > On Aug 9, 2020, at 12:35 PM, Duncan Murdoch <murdoch.dun...@gmail.com> > > wrote: > > > > On 09/08/2020 3:15 p.m., Ben Bolker wrote: > >> On 8/9/20 3:08 PM, Duncan Murdoch wrote: > >>> On 09/08/2020 2:59 p.m., John Mount wrote: > >>>> Firstly: thanks to Ben for the help/fix. > >>>> > >>>> I know nobody asked, but. > >>>> > >>>> Having to guess where the documentation is just to refer to it is > >>>> just going to be really brittle going forward. Previous: if the > >>>> function you referred to existed in the package you were fine. > >>> > >>> That's not correct. The system could often work around the error, but > >>> not always. > >> I may be missing something. It may well be that referring to a > >> cross-package link by alias rather than by the name of the Rd page > >> actually never worked, but: would there be a big barrier to making > >> cross-package documentation links be able to follow aliases? I can > >> imagine there may be technical hurdles but it seems like a well-defined > >> problem ... > > > > To link to "?utils::dump.frames", you need to construct a URL that leads to > > the HTML file containing that help page on static builds of the help system. > > > > If utils is available, no problem, just look up the fact that the page you > > want is debugger.html at the time you construct the link. But it was > > documented that such links should work even if the target package was not > > available at the time the link was being made. So you need a link that you > > are sure will be available when the referenced package is eventually > > installed. Obviously that's going to be brittle. > > > > Perhaps the new requirement that referenced packages be mentioned in the > > DESCRIPTION file is a step towards addressing this. If everything that's > > referenced is present when the help system is being built, there will be an > > easy solution. > > > > Nowadays, it would probably be reasonable to put in stub pages for every > > alias, so that when you try to load dump.frames.html, the page itself > > redirects you to debugger.html. Or maybe you could just have a single page > > in each package that handles aliases via Javascript. > > > > Or R could just no longer support static copies of the help system. > > > > When you are using dynamically generated help pages, the link can be > > resolved by the server, and that's why those links have appeared to work > > for so long, even though the requirement to link to the filename instead of > > the alias has been there since before I wrote the dynamic help server. > > > > Duncan Murdoch > > > >>> > >>> Duncan Murdoch > >>> > >>> > >>> Future: if don't correctly specify where the help is you are wrong. > >>> Going forward: reorganizing a package's help can break referring > >>> packages. This sort of brittleness is going to be a big time-waster > >>> going forward. It seems like really the wrong direction in packaging, > >>> isolation, and separation of concerns (SOLID style principles). > >>>> > >>>>> On Aug 9, 2020, at 11:04 AM, Ben Bolker <bbol...@gmail.com> wrote: > >>>>> > >>>>> This might have to be \link[utils:debugger]{dump.frames} now, i.e. > >>>>> explicitly linking to the man page on which dump.frames is found > >>>>> rather than following aliases? > >>>>> > >>>>> On Sun, Aug 9, 2020 at 2:01 PM John Mount <jmo...@win-vector.com> > >>>>> wrote: > >>>>>> > >>>>>> With "R Under development (unstable) (2020-07-05 r78784)" (Windows) > >>>>>> documentation references such as "\link[utils]{dump.frames}" > >>>>>> trigger "Non-file package-anchored link(s) in documentation object" > >>>>>> warnings even if the package is in your "Imports." > >>>>>> > >>>>>> Is that not the right form? Is there any way to fix this other than > >>>>>> the workaround of just removing links from the documentation? I > >>>>>> kind of don't want to do that as the links were there to help the > >>>>>> user. > >>>>>> > >>>>>> ______________________________________________ > >>>>>> R-package-devel@r-project.org mailing list > >>>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel > >>>> > >>>> ______________________________________________ > >>>> R-package-devel@r-project.org mailing list > >>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel > >>>> > >>> > > > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
