Re: [R-pkg-devel] WARNING: A complete check needs the 'checkbashisms' script.
Hi Brian, The checkbashisms script is invoked by the R checks automatically: https://github.com/wch/r-source/blob/trunk/src/library/tools/R/check.R#L1216-L1267 Thus there shouldn't be any need for you to invoke it manually in your configure script, even less so to worry about its presence. You can still install it locally so the R checks can proceed without the warning (or set _R_CHECK_BASHISMS_ to FALSE to skip that particular check, again locally), but that shouldn't be a problem in CRAN, as it should be installed there already. Cheers, Rodrigo On 11/8/20 10:54 am, brian knaus wrote: Hi R-pkg-devel, My package https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fknausb%2FvcfRdata=02%7C01%7Crodrigo.tobarcarrizo%40uwa.edu.au%7C6f00588f63164cc6f8d208d83da1e836%7C05894af0cb2846d8871674cdb46e2226%7C1%7C0%7C637327112896039359sdata=afGjqTjB%2B8lVCmXDWb8OhFNIYwIR%2BoIVX1QLFpLSfwA%3Dreserved=0 has been archived on CRAN because I was asked by CRAN to address issues that I was unable to address before the deadline I was given. The issue I'm struggling with is that when I use ``` R CMD check --as-cran vcfR_1.12.0.tar.gz ``` I get ``` * checking top-level files ... WARNING A complete check needs the 'checkbashisms' script. See section ‘Configure and cleanup’ in the ‘Writing R Extensions’ manual.. ``` . Dirk Eddelbeuttel has proposed a solution on SO. (Thank you again Dirk!) ``` https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fa%2F62721142data=02%7C01%7Crodrigo.tobarcarrizo%40uwa.edu.au%7C6f00588f63164cc6f8d208d83da1e836%7C05894af0cb2846d8871674cdb46e2226%7C1%7C0%7C637327112896039359sdata=G5BGCuyWMSItqbm0zwWbncrGapgNUldsuOIp6RvQlqs%3Dreserved=0 ``` I've implemented this change, but I am concerned that it won't be accepted by CRAN. My concern is that this works on my local machines (Ubuntu and MacOS), where I can install checkbashisms, but I can't control whether checkbashisms is installed on CRAN machines or on user machines. This means it will generate a WARNING on machines where checkbashisms is not installed. Most of me feels that I need to address this somehow. But I do not know how. Part of me is wondering if I should expect users to manage this. Any help would be appreciated! Thank you! Brian (knausb) [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-develdata=02%7C01%7Crodrigo.tobarcarrizo%40uwa.edu.au%7C6f00588f63164cc6f8d208d83da1e836%7C05894af0cb2846d8871674cdb46e2226%7C1%7C0%7C637327112896039359sdata=7zy%2BLfU7WVDBzP0sP0axZpg8MF4AsD5wtrTu3plbF3o%3Dreserved=0 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] WARNING: A complete check needs the 'checkbashisms' script.
Hi R-pkg-devel, My package https://github.com/knausb/vcfR has been archived on CRAN because I was asked by CRAN to address issues that I was unable to address before the deadline I was given. The issue I'm struggling with is that when I use ``` R CMD check --as-cran vcfR_1.12.0.tar.gz ``` I get ``` * checking top-level files ... WARNING A complete check needs the 'checkbashisms' script. See section ‘Configure and cleanup’ in the ‘Writing R Extensions’ manual.. ``` . Dirk Eddelbeuttel has proposed a solution on SO. (Thank you again Dirk!) ``` https://stackoverflow.com/a/62721142 ``` I've implemented this change, but I am concerned that it won't be accepted by CRAN. My concern is that this works on my local machines (Ubuntu and MacOS), where I can install checkbashisms, but I can't control whether checkbashisms is installed on CRAN machines or on user machines. This means it will generate a WARNING on machines where checkbashisms is not installed. Most of me feels that I need to address this somehow. But I do not know how. Part of me is wondering if I should expect users to manage this. Any help would be appreciated! Thank you! Brian (knausb) [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Package Anchored Links with R-Dev
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 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
> > 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 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
> > 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
Re: [R-pkg-devel] Package Anchored Links with R-Dev
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 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 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
> 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
