[R-pkg-devel] how to address CRAN FAIL on r-devel-windows-x86_64-gcc10-UCRT?

[Daniel Kelley]

The "oce" package for oceanographic analysis is failing a check on the 
r-devel-windows-x86_64-gcc10-UCRT system (see
https://www.r-project.org/nosvn/R.check/r-devel-windows-x86_64-gcc10-UCRT/oce-00check.html).
 The problem seems to relate to the checking vignette outputs.

According to 
https://www.r-project.org/nosvn/winutf8/ucrt3/CRAN/checks/gcc10-UCRT/README.txt,
 that test setup is experimental.  Does that mean that I ought to I ignore the 
FAIL status for this machine, perhaps checking it once in a while to see if it 
changes?

Alternatively, if I am advised to fix the problem, I wonder whether there a way 
for me to run tests with rhub, winbuilder, or something similar?  (I do not 
have access to a windows machine.)

Thanks in advance for any help that can be provided.

Dan Kelley, Dept. Oceanography, Dalhousie University, Canada
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Using RC_fopen in a CRAN package

[David Cortes]

I’d like to ask for clarification about CRAN policies regarding usage
of functions that start with "RC_*", such as "RC_fopen".

I'm trying to upload a package which is meant for reading and writing
data from text files in a certain format, for which I want to use a C
file pointer which I obtain through "RC_fopen". The R extensions manual
says the following:
"... there are other header files there that can be included too, but
many of the features they contain should be regarded as undocumented
and unstable."

Since "RC_fopen" is present in a header file, I would guess it should
be classified as "public" within the entry points classification
(between API/public/private/hidden). This is the description for such
entry points in the manual:
"Entry points declared in an installed header file that are exported on
all R platforms but are not documented and subject to change without
notice."

As I understand it, there is nothing that would forbid using public
entry points compared to the explicit point made about "private" entry
points. However, when I try to submit the package to CRAN, it doesn't
make it past the automated checks due to a NOTE:
Check: compiled code, Result: NOTE
  File 'readsparse/libs/readsparse.so':
Found non-API call to R: 'RC_fopen'
  
  Compiled code should not call non-API entry points in R.
  
  See 'Writing portable packages' in the 'Writing R Extensions' manual.


Is it allowed to use such functions in packages? I see a few packages
currently in CRAN have the same note in the checks, such as "iotools",
and am wondering if I should just email the CRAN maintainer explaining
that I intend to use the function anyway, since it's just a note rather
than a warning or error.

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Using RC_fopen in a CRAN package

[Duncan Murdoch]

On 01/04/2021 9:06 p.m., David Cortes wrote:

I’d like to ask for clarification about CRAN policies regarding usage
of functions that start with "RC_*", such as "RC_fopen".

I'm trying to upload a package which is meant for reading and writing
data from text files in a certain format, for which I want to use a C
file pointer which I obtain through "RC_fopen". The R extensions manual
says the following:
"... there are other header files there that can be included too, but
many of the features they contain should be regarded as undocumented
and unstable."

Since "RC_fopen" is present in a header file, I would guess it should
be classified as "public" within the entry points classification
(between API/public/private/hidden). This is the description for such
entry points in the manual:
"Entry points declared in an installed header file that are exported on
all R platforms but are not documented and subject to change without
notice."

As I understand it, there is nothing that would forbid using public
entry points compared to the explicit point made about "private" entry
points. However, when I try to submit the package to CRAN, it doesn't
make it past the automated checks due to a NOTE:
Check: compiled code, Result: NOTE
   File 'readsparse/libs/readsparse.so':
 Found non-API call to R: 'RC_fopen'
   
   Compiled code should not call non-API entry points in R.
   
   See 'Writing portable packages' in the 'Writing R Extensions' manual.



Is it allowed to use such functions in packages? I see a few packages
currently in CRAN have the same note in the checks, such as "iotools",
and am wondering if I should just email the CRAN maintainer explaining
that I intend to use the function anyway, since it's just a note rather
than a warning or error.


The CRAN policy document is quite clear on this: "CRAN packages should 
use only the public API. Hence they should not use entry points not 
declared as API in installed headers nor .Internal() nor .Call() etc 
calls to base packages. Also, ::: should not be used to access 
undocumented/internal objects in base packages (nor should other means 
of access be employed). Such usages can cause packages to break at any 
time, even in patched versions of R. "


So you are free to use that function, but CRAN won't publish your 
package if you do.


Duncan Murdoch

Duncan Murdoch

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Using RC_fopen in a CRAN package

[Dirk Eddelbuettel]

On 2 April 2021 at 09:45, Duncan Murdoch wrote:
| On 01/04/2021 9:06 p.m., David Cortes wrote:
| > Is it allowed to use such functions in packages? I see a few packages
| > currently in CRAN have the same note in the checks, such as "iotools",
| > and am wondering if I should just email the CRAN maintainer explaining
| > that I intend to use the function anyway, since it's just a note rather
| > than a warning or error.
| 
| The CRAN policy document is quite clear on this: "CRAN packages should 
| use only the public API. Hence they should not use entry points not 
| declared as API in installed headers nor .Internal() nor .Call() etc 
| calls to base packages. Also, ::: should not be used to access 
| undocumented/internal objects in base packages (nor should other means 
| of access be employed). Such usages can cause packages to break at any 
| time, even in patched versions of R. "
| 
| So you are free to use that function, but CRAN won't publish your 
| package if you do.

What you can do is to republish the functions in a package you own and
maintain, and then export them from there. I have done that in RApiDatetime
for some date/time parsing code, and in RApiSerialize for serialization.

It is not ideal as your copies may become stale over time. But it gives you a
way forward as long as R Core exercises their right to have non-public APIs.
As R Core has demonstrated exemplary fidelity to the parts of the API that
are public, we should not be too grumpy that they reserve this option.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] how to address CRAN FAIL on r-devel-windows-x86_64-gcc10-UCRT?

[David Winsemius]

On 4/2/21 4:05 AM, Daniel Kelley wrote:

The "oce" package for oceanographic analysis is failing a check on the 
r-devel-windows-x86_64-gcc10-UCRT system (see
https://www.r-project.org/nosvn/R.check/r-devel-windows-x86_64-gcc10-UCRT/oce-00check.html).
 The problem seems to relate to the checking vignette outputs.

According to 
https://www.r-project.org/nosvn/winutf8/ucrt3/CRAN/checks/gcc10-UCRT/README.txt,
 that test setup is experimental.  Does that mean that I ought to I ignore the 
FAIL status for this machine, perhaps checking it once in a while to see if it 
changes?

Hello Daniel;

I'm not speaking for CRAN. I'm another maintainer whose current status 
page has a FAIL for that platform. But the FAIL notation is due at least 
in part to the fact that apparently the UCRT platform is less frequently 
run on the full CRAN package holdings. The note refers to a package that 
was updated a few days ago. The log file however has two other reports 
of failure relating to compiler warnings.


All the other platforms passed the newer versions. There is no mention 
of the UCRT platform at the CRAN Policies page: 
https://cran.r-project.org/web/packages/policies.html


I'm waiting to see whether the aging fortran code generates warnings 
whenever the UCRT platform gets fired up again.


--

David Winsemius

maintainer (but neither author or contributor) of "muhaz"



Alternatively, if I am advised to fix the problem, I wonder whether there a way 
for me to run tests with rhub, winbuilder, or something similar?  (I do not 
have access to a windows machine.)

Thanks in advance for any help that can be provided.

Dan Kelley, Dept. Oceanography, Dalhousie University, Canada
__
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] checking LazyData ... NOTE 'LazyData' is specified without a 'data' directory

[Uwe Ligges]

On 01.04.2021 07:55, Tim Hulsen wrote:

r-release-windows-ix86+x86_64


A new check, you declare LazyData in your DESCRIPTION file which is 
meaningless. So please simply omit that line.


Best,
Uwe Ligges


Op wo 31 mrt. 2021 om 14:31 schreef Duncan Murdoch 
:



On 31/03/2021 8:28 a.m., Tim Hulsen wrote:

I don’t believe I do anything with lazydata.


Your DESCRIPTION file specifies it is TRUE.

Duncan Murdoch



https://cran.r-project.org/web/checks/check_results_BioVenn.html





Op 31 mrt. 2021 om 14:24 heeft Duncan Murdoch
 het volgende geschreven:

On 31/03/2021 5:55 a.m., Tim Hulsen wrote:

When submitting my package to CRAN, I get the message:
checking LazyData ... NOTE
'LazyData' is specified without a 'data' directory
What can i do about this?


Don't specify LazyData.  If that doesn't help, give us a bit more
information, e.g. a link to your source.

Duncan Murdoch





[[alternative HTML version deleted]]

__
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