Re: [R-pkg-devel] CRAN packages dependency on bioconductor packages
On 16.05.2024 10:15, Sebastian Meyer wrote:
Am 15.05.24 um 00:09 schrieb Lluís Revilla:
Hi Junhui,
There is a separate log for checking if your package works without
suggested packages: in the StepReg results
The noSuggests title leads to:
https://www.stats.ox.ac.uk/pub/bdr/noSuggests/StepReg.out
Where you can see that it fails if a user don't have BiocStyle installed.
I don't know if it is possible to use a vignette output conditionally
with
knitr: In any case it seems that it would be a requirement (Imports, or
Depends).
Yes, I'd consider the package providing the vignette output format for
the rmarkdown engine, here BiocStyle, as a strong dependency of that
vignette. The error from the additional "noSuggests" check
(<https://www.stats.ox.ac.uk/pub/bdr/noSuggests/README.txt>) shows it
cannot be rebuild if BiocStyle is unavailable.
The 'StepReg' vignette could use a metadata line to declare strong
vignette dependencies, for example:
%\VignetteDepends{StepReg, BiocStyle, kableExtra}
Indeed, having it listed in Suggests plus the \VignetteDepends
declaration should suffice.
Best,
Uwe Ligges
(I haven't checked if this list is complete.)
This avoids spurious check errors in incomplete setups, such as when
mass-checking packages (e.g., reverse dependencies) without some of the
suggested packages being installed.
Best,
Sebastian Meyer
However, it is best to not use the Bioconductor style for a package in
CRAN.
You could use the *_vignette or *_document format directly (from
rmarkdown
if I recall correctly).
You will remove a dependency and avoid this problem entirely.
Best,
Lluís
On Tue, 14 May 2024 at 22:48, Li, Junhui
wrote:
Hi everyone,
I recently developed an R package called 'StepReg' and used the
Bioconductor R package 'BiocStyle' in my vignettes, as shown below:
output:
BiocStyle::html_document:
toc_float: true
BiocStyle::pdf_document: default
In my DESCRIPTION file, I added 'BiocStyle' to the Suggests field and
included a new line 'biocViews:', as follows:
VignetteBuilder: knitr
biocViews:
Suggests:
knitr,
testthat,
BiocStyle,
kableExtra
You may find all those information here:
https://github.com/JunhuiLi1017/StepReg/tree/dev
There were no error messages when checking with 'R CMD check' and on
https://win-builder.r-project.org/upload.aspx. However, an error message
occurred when I attempted to upload it to CRAN:
* checking re-building of vignette outputs ... ERROR
Error(s) in re-building vignettes:
--- re-building 'StepReg.Rmd' using rmarkdown
Error: processing vignette 'StepReg.Rmd' failed with diagnostics:
there is no package called 'BiocStyle'
--- failed re-building 'StepReg.Rmd'
SUMMARY: processing the following file failed:
'StepReg.Rmd'
Error: Vignette re-building failed.
Execution halted
For version 1.5.0 (
https://cran.r-project.org/web/packages/StepReg/index.html), I
successfully uploaded it to CRAN without including 'biocViews:' in the
DESCRIPTION file two months ago. However, I'm encountering difficulties
this time. Any insights or suggestions on resolving this issue would be
greatly appreciated.
Thanks,
Junhui
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[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
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] package removed from CRAN
On 08.05.2024 17:30, Jose V. Die Ramon wrote: Hello, I just discovered that my package 'refseqR' was removed from the CRAN repository on April 30th. https://cran.r-project.org/web/packages/refseqR/index.html This news is extremely upsetting, especially because I did not receive any communication or warning regarding the issue. Could anyone please help me understand the reasons behind this, or suggest any steps I should take to resolve it? Thanks, Jose Professor Ripley sent you email on April 16 and asked for a fix within 2 weeks --- to your maintainer address which is apparently different from the one you are using here. Best, Uwe Ligges __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement
On 08.05.2024 17:56, Josiah Parry wrote: Thank you, Dirk. This was a direct email from a CRAN member and not part of the automatic checks. The whole email is below. I think the intent of the message is "please resubmit." Well, the CRAN maintainer has not spotted this is abour rust code. This was not indicated in your mail, hence you got direct rejection. Best, Uwe Ligges Thanks, we see: Size of tarball: 18099770 bytes Please reudce to less than 5 MB for a CRAN package. Best, Yes, prqlr is a great Rust-based package! My other Rust based packages that are on CRAN are based, in part on prqlr. On Wed, May 8, 2024 at 11:51 AM Dirk Eddelbuettel wrote: On 8 May 2024 at 11:02, Josiah Parry wrote: | CRAN has rejected this package with: | | * Size of tarball: 18099770 bytes* | | *Please reudce to less than 5 MB for a CRAN package.* Are you by chance confusing a NOTE (issued, but can be overruled) with a WARNING (more severe, likely a must-be-addressed) or ERROR? There are lots and lots of packages larger than 5mb -- see eg https://cran.r-project.org/src/contrib/?C=S;O=D which has a top-5 of rcdklibs 19mb fastrmodels15mb prqlr 15mb RFlocalfdr 14mb acss.data 14mb and at least one of those is also Rust-using and hence a possible template. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org [[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
Re: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN
On 18.04.2024 15:48, Uwe Ligges wrote:
On 18.04.2024 15:43, Ben Bolker wrote:
To clarify, from an off-list conversation:
AFAICT the chain is
dotwhisker Imports
margins, which Imports
prediction, which Enhances
ffbase (archived in 2022 for 'coercion to logical' problems)
(that conversation also pointed out that Enhances is a dependency
*in the opposite direction* -- i.e. if A Enhances B, it's not entirely
clear why the disappearance of B should matter at all ...)
The year old check notes in prediciton matter, not the level of any
dependencies.
.. and even more the non-maintainance state of prediction.
Best,
Uwe Ligges
Best,
Uwe Ligges
On 2024-04-18 9:35 a.m., Ben Bolker wrote:
Yes, but ffbase was archived a long time ago (2022-04-04) and
CRAN has apparently just caught up to checking. What's a little
frustrating (to me) is that the dependence of prediction on ffbase is
*very* soft ("enhances") ...
On 2024-04-18 9:28 a.m., Thierry Onkelinx wrote:
The cascade is even longer. prediction got archived because ffbase
was no longer available.
https://cran.r-project.org/web/packages/ffbase/
<https://cran.r-project.org/web/packages/ffbase/>
ir. Thierry Onkelinx
Statisticus / Statistician
Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR
NATURE AND FOREST
Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkel...@inbo.be <mailto:thierry.onkel...@inbo.be>
Havenlaan 88 bus 73, 1000 Brussel
*Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel
/Poststukken die naar dit adres worden gestuurd, worden ingescand en
digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid
haar dossiers volledig digitaal behandelen. Poststukken met de
vermelding ‘vertrouwelijk’ worden niet ingescand, maar ongeopend aan
de geadresseerde bezorgd./
www.inbo.be <http://www.inbo.be>
///
To call in the statistician after the experiment is done may be no
more than asking him to perform a post-mortem examination: he may be
able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does
not ensure that a reasonable answer can be extracted from a given
body of data. ~ John Tukey
///
<https://www.inbo.be>
Op do 18 apr 2024 om 15:25 schreef Ben Bolker <mailto:bbol...@gmail.com>>:
Thank you! (I know about package_dependencies() but ran into
precisely the same problem and didn't want to re-implement it ...)
On 2024-04-18 9:11 a.m., Josiah Parry wrote:
> Well, after trying to install the package, I believe the
issue is
> because margins has been archived.
>
> https://cran.r-project.org/web/packages/margins/index.html
<https://cran.r-project.org/web/packages/margins/index.html>
> <https://cran.r-project.org/web/packages/margins/index.html
<https://cran.r-project.org/web/packages/margins/index.html>>
>
> You can check recursive dependencies using
> `tools::package_dependencies("pkg", recursive = TRUE)` which
would help
> you in this case. I couldn't run it since the package is not
available
> on CRAN, however.
>
>
> On Thu, Apr 18, 2024 at 9:05 AM Ben Bolker mailto:bbol...@gmail.com>
> <mailto:bbol...@gmail.com <mailto:bbol...@gmail.com>>> wrote:
>
> The 'dotwhisker' package was archived on CRAN: from
> https://cran.r-project.org/web/packages/dotwhisker/index.html
<https://cran.r-project.org/web/packages/dotwhisker/index.html>
> <https://cran.r-project.org/web/packages/dotwhisker/index.html
<https://cran.r-project.org/web/packages/dotwhisker/index.html>>
>
> Package ‘dotwhisker’ was removed from the CRAN
repository
> ...
>
> Archived on 2024-04-12 as requires archived package
'prediction'.
>
> However, I can't for the life of me see where this
dependence
> could
> come from. Neither the DESCRIPTION file of the last-archived
version on
> CRAN
>
<https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz> <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz>>>,
>
Re: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN
On 18.04.2024 15:43, Ben Bolker wrote:
To clarify, from an off-list conversation:
AFAICT the chain is
dotwhisker Imports
margins, which Imports
prediction, which Enhances
ffbase (archived in 2022 for 'coercion to logical' problems)
(that conversation also pointed out that Enhances is a dependency *in
the opposite direction* -- i.e. if A Enhances B, it's not entirely clear
why the disappearance of B should matter at all ...)
The year old check notes in prediciton matter, not the level of any
dependencies.
Best,
Uwe Ligges
On 2024-04-18 9:35 a.m., Ben Bolker wrote:
Yes, but ffbase was archived a long time ago (2022-04-04) and CRAN
has apparently just caught up to checking. What's a little
frustrating (to me) is that the dependence of prediction on ffbase is
*very* soft ("enhances") ...
On 2024-04-18 9:28 a.m., Thierry Onkelinx wrote:
The cascade is even longer. prediction got archived because ffbase
was no longer available.
https://cran.r-project.org/web/packages/ffbase/
<https://cran.r-project.org/web/packages/ffbase/>
ir. Thierry Onkelinx
Statisticus / Statistician
Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR
NATURE AND FOREST
Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkel...@inbo.be <mailto:thierry.onkel...@inbo.be>
Havenlaan 88 bus 73, 1000 Brussel
*Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel
/Poststukken die naar dit adres worden gestuurd, worden ingescand en
digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid
haar dossiers volledig digitaal behandelen. Poststukken met de
vermelding ‘vertrouwelijk’ worden niet ingescand, maar ongeopend aan
de geadresseerde bezorgd./
www.inbo.be <http://www.inbo.be>
///
To call in the statistician after the experiment is done may be no
more than asking him to perform a post-mortem examination: he may be
able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does
not ensure that a reasonable answer can be extracted from a given
body of data. ~ John Tukey
///
<https://www.inbo.be>
Op do 18 apr 2024 om 15:25 schreef Ben Bolker <mailto:bbol...@gmail.com>>:
Thank you! (I know about package_dependencies() but ran into
precisely the same problem and didn't want to re-implement it ...)
On 2024-04-18 9:11 a.m., Josiah Parry wrote:
> Well, after trying to install the package, I believe the issue is
> because margins has been archived.
>
> https://cran.r-project.org/web/packages/margins/index.html
<https://cran.r-project.org/web/packages/margins/index.html>
> <https://cran.r-project.org/web/packages/margins/index.html
<https://cran.r-project.org/web/packages/margins/index.html>>
>
> You can check recursive dependencies using
> `tools::package_dependencies("pkg", recursive = TRUE)` which
would help
> you in this case. I couldn't run it since the package is not
available
> on CRAN, however.
>
>
> On Thu, Apr 18, 2024 at 9:05 AM Ben Bolker mailto:bbol...@gmail.com>
> <mailto:bbol...@gmail.com <mailto:bbol...@gmail.com>>> wrote:
>
> The 'dotwhisker' package was archived on CRAN: from
> https://cran.r-project.org/web/packages/dotwhisker/index.html
<https://cran.r-project.org/web/packages/dotwhisker/index.html>
> <https://cran.r-project.org/web/packages/dotwhisker/index.html
<https://cran.r-project.org/web/packages/dotwhisker/index.html>>
>
> Package ‘dotwhisker’ was removed from the CRAN
repository
> ...
>
> Archived on 2024-04-12 as requires archived package
'prediction'.
>
> However, I can't for the life of me see where this
dependence
> could
> come from. Neither the DESCRIPTION file of the last-archived
version on
> CRAN
>
<https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz> <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz>>>,
> nor the version on github
<https://github.com/fsolt/dotwhisker
<https://github.com/fsolt/dotwh
Re: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN
On 18.04.2024 15:35, Ben Bolker wrote:
Yes, but ffbase was archived a long time ago (2022-04-04) and CRAN
has apparently just caught up to checking. What's a little frustrating
(to me) is that the dependence of prediction on ffbase is *very* soft
("enhances") ...
No, but CRAN has still not received an update and asked for this each
month this year, so in Jan, Feb, and March without a response, so we
assume prediction is unmaintained. Also, this was escalated to reverse
depends.
Best,
Uwe Ligges
On 2024-04-18 9:28 a.m., Thierry Onkelinx wrote:
The cascade is even longer. prediction got archived because ffbase was
no longer available. https://cran.r-project.org/web/packages/ffbase/
<https://cran.r-project.org/web/packages/ffbase/>
ir. Thierry Onkelinx
Statisticus / Statistician
Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE
AND FOREST
Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkel...@inbo.be <mailto:thierry.onkel...@inbo.be>
Havenlaan 88 bus 73, 1000 Brussel
*Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel
/Poststukken die naar dit adres worden gestuurd, worden ingescand en
digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid haar
dossiers volledig digitaal behandelen. Poststukken met de vermelding
‘vertrouwelijk’ worden niet ingescand, maar ongeopend aan de
geadresseerde bezorgd./
www.inbo.be <http://www.inbo.be>
///
To call in the statistician after the experiment is done may be no
more than asking him to perform a post-mortem examination: he may be
able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does
not ensure that a reasonable answer can be extracted from a given body
of data. ~ John Tukey
///
<https://www.inbo.be>
Op do 18 apr 2024 om 15:25 schreef Ben Bolker <mailto:bbol...@gmail.com>>:
Thank you! (I know about package_dependencies() but ran into
precisely the same problem and didn't want to re-implement it ...)
On 2024-04-18 9:11 a.m., Josiah Parry wrote:
> Well, after trying to install the package, I believe the issue is
> because margins has been archived.
>
> https://cran.r-project.org/web/packages/margins/index.html
<https://cran.r-project.org/web/packages/margins/index.html>
> <https://cran.r-project.org/web/packages/margins/index.html
<https://cran.r-project.org/web/packages/margins/index.html>>
>
> You can check recursive dependencies using
> `tools::package_dependencies("pkg", recursive = TRUE)` which
would help
> you in this case. I couldn't run it since the package is not
available
> on CRAN, however.
>
>
> On Thu, Apr 18, 2024 at 9:05 AM Ben Bolker mailto:bbol...@gmail.com>
> <mailto:bbol...@gmail.com <mailto:bbol...@gmail.com>>> wrote:
>
> The 'dotwhisker' package was archived on CRAN: from
> https://cran.r-project.org/web/packages/dotwhisker/index.html
<https://cran.r-project.org/web/packages/dotwhisker/index.html>
>
<https://cran.r-project.org/web/packages/dotwhisker/index.html
<https://cran.r-project.org/web/packages/dotwhisker/index.html>>
>
> Package ‘dotwhisker’ was removed from the CRAN
repository
> ...
>
> Archived on 2024-04-12 as requires archived package
'prediction'.
>
> However, I can't for the life of me see where this
dependence
> could
> come from. Neither the DESCRIPTION file of the last-archived
version on
> CRAN
>
<https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz> <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz <https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz>>>,
> nor the version on github
<https://github.com/fsolt/dotwhisker
<https://github.com/fsolt/dotwhisker>
> <https://github.com/fsolt/dotwhisker
<https://github.com/fsolt/dotwhisker>>>, seem to
> show any signs of importing prediction ... ?? I suppose
there's a
> possibility of a recursive dependence, but in that case why
wouldn't
> the
> direct
Re: [R-pkg-devel] Linking Tutorial Site to CRAN Package site.
Use the URL firld of the package. Best, Uwe Ligges On 06.04.2024 20:27, Ruff, Sergej wrote: Hello, I was wondering if its possible to link the toturial site for a package on the CRAN Cite to the package? I want to publish the next version of our package. The CRAN site (https://cran.r-project.org/web/packages/RepeatedHighDim/index.html) has a "documentation" part with the refrence pdf. Can I link to our tutorial site (https://software.klausjung-lab.de/.) under documentation? Sergej [[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
Re: [R-pkg-devel] Order of repo access from options("repos")
If your company is going to ensure that a package called pkgCompany is only looked for in a local repo by installl.packages() and friends, I think in your cpmpany wide R installation you can set the option "available_packages_filters" to a self written one that is exclusively reporting results from the local repo for 'pkgCompany'. Of course, this is not safe and can be overwritten by e user etc., but it needs quite some effort to trick people this way in using a malicious package from another repo. It would be simpler for attackers to persuade people to install the malicious software directly, I believe. Best, Uwe Ligges On 02.04.2024 16:05, Jan van der Laan wrote: Interesting. That would also mean that putting a company repo first does not protect against dependency confusion attacks (people intentionally uploading packages with the same name as company internal packages on CRAN; https://arstechnica.com/information-technology/2021/02/supply-chain-attack-that-fooled-apple-and-microsoft-is-attracting-copycats/) Jan On 01-04-2024 02:07, Greg Hunt wrote: Martin, Dirk, Kevin, Thanks for your help. To summarise: the order of access is undefined, and every repo URL is accessed. I'm working in an environment where "known-good" is more important than "latest", so what follows is an explanation of the problem space from my perspective. What I am experimenting with is pinning down the versions of the packages that a moderately complex solution is built against using a combination of an internal repository of cached packages (internally written packages, our own hopefully transient copies of packages archived from CRAN, packages live on CRAN, and packages present in both Github and CRAN which we build and cache locally) and a proxy that separately populates that cache in specific build processes by intercepting requests to CRAN. I'd like to use the base R function if possible and I want to let the version numbers in the dependencies float because a) we do need to maintain approximate currency in what versions of packages we use and b) I have no business monkeying around with third party's dependencies. Renv looks helpful but has some assumptions about disk access to its cache that I'd rather avoid by running an internal repo. The team is spread around the world, so shared cache volumes are not a great idea. The business with the multiple repo addresses is one approach to working around Docker's inability to understand that people need to access the Docker host's ports from inside a container or a build, and that the current Docker treatment of the host's internal IP is far from transparent (I have scripts that run both inside and outside of Docker containers and they used to be able to work out for themselves what environment they run in, thats got harder lately). That led down a path in which one set of addresses did not reject connection attempts, making each package installation (and there are hundreds) take some number of minutes for the connections to time out. Thankfully I don't actually have to deal with that. We have had a few cases where our dependencies have been archived from CRAN and we have maintained our own copy for a period of days to months, a period in which we do not know what the next package version number is. It would be convenient to not have to think about that - a deterministic, terminating search of a sequence of repos looked like a nice idea for that, but I may have to do something different. There was a recent case where a package made a breaking change in its interface in a release (not version) update that broke another package we depend on. It would be nice to be able to temporarily pin that package at its previous version (without updating the source of the third party package that depends on it) to preserve our own build-ability while those packages sort themselves out. There is one case where a pull request for a CRAN-hosted package was verbally accepted but never actioned so we have our own forked version of a CRAN-hosted package which I need to decide what to do with one day soon. Another case where the package version number is different in CRAN from the one we want. We have a dependency on a package that we build from a Git repo but which is also present in CRAN. I don't want to be dependent on the maintainers keeping the package version in the Git copy of the DESCRIPTION file higher than the version in CRAN. Ideally I'd like to build and push to the internal repo and not have to think about it after that. Same issue as before arises, as it stands today I have to either worry about, and probably edit, the version number in the build or manage the cache population process so the internal package instance is added after any CRAN-sourced dependencies and make sure that the public CRAN instances are not accessed in the build. All of these problems are soluble by special
Re: [R-pkg-devel] Order of repo access from options("repos")
On 02.04.2024 14:07, Dirk Eddelbuettel wrote: On 1 April 2024 at 17:44, Uwe Ligges wrote: | Untested: | | install.packages() calls available.packages() to find out which packages | are available - and passes a "filters" argument if supplied. | That can be a user defined filter. It should be possible to write a user | defined filter which prefers the packages in your local repo. Intriguing. Presumably that would work for update.packages() too? Yes. I think so. Best, Uwe (We actually have a use case at work, and as one way out I created another side-repo to place a package with an incremented version number so it would 'win' on hightest version; this is due to some non-trivial issues with the underlying dependencies.) Dirk __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Order of repo access from options("repos")
Untested: install.packages() calls available.packages() to find out which packages are available - and passes a "filters" argument if supplied. That can be a user defined filter. It should be possible to write a user defined filter which prefers the packages in your local repo. Best, Uwe Ligges On 01.04.2024 02:07, Greg Hunt wrote: Martin, Dirk, Kevin, Thanks for your help. To summarise: the order of access is undefined, and every repo URL is accessed. I'm working in an environment where "known-good" is more important than "latest", so what follows is an explanation of the problem space from my perspective. What I am experimenting with is pinning down the versions of the packages that a moderately complex solution is built against using a combination of an internal repository of cached packages (internally written packages, our own hopefully transient copies of packages archived from CRAN, packages live on CRAN, and packages present in both Github and CRAN which we build and cache locally) and a proxy that separately populates that cache in specific build processes by intercepting requests to CRAN. I'd like to use the base R function if possible and I want to let the version numbers in the dependencies float because a) we do need to maintain approximate currency in what versions of packages we use and b) I have no business monkeying around with third party's dependencies. Renv looks helpful but has some assumptions about disk access to its cache that I'd rather avoid by running an internal repo. The team is spread around the world, so shared cache volumes are not a great idea. The business with the multiple repo addresses is one approach to working around Docker's inability to understand that people need to access the Docker host's ports from inside a container or a build, and that the current Docker treatment of the host's internal IP is far from transparent (I have scripts that run both inside and outside of Docker containers and they used to be able to work out for themselves what environment they run in, thats got harder lately). That led down a path in which one set of addresses did not reject connection attempts, making each package installation (and there are hundreds) take some number of minutes for the connections to time out. Thankfully I don't actually have to deal with that. We have had a few cases where our dependencies have been archived from CRAN and we have maintained our own copy for a period of days to months, a period in which we do not know what the next package version number is. It would be convenient to not have to think about that - a deterministic, terminating search of a sequence of repos looked like a nice idea for that, but I may have to do something different. There was a recent case where a package made a breaking change in its interface in a release (not version) update that broke another package we depend on. It would be nice to be able to temporarily pin that package at its previous version (without updating the source of the third party package that depends on it) to preserve our own build-ability while those packages sort themselves out. There is one case where a pull request for a CRAN-hosted package was verbally accepted but never actioned so we have our own forked version of a CRAN-hosted package which I need to decide what to do with one day soon. Another case where the package version number is different in CRAN from the one we want. We have a dependency on a package that we build from a Git repo but which is also present in CRAN. I don't want to be dependent on the maintainers keeping the package version in the Git copy of the DESCRIPTION file higher than the version in CRAN. Ideally I'd like to build and push to the internal repo and not have to think about it after that. Same issue as before arises, as it stands today I have to either worry about, and probably edit, the version number in the build or manage the cache population process so the internal package instance is added after any CRAN-sourced dependencies and make sure that the public CRAN instances are not accessed in the build. All of these problems are soluble by special-casing the affected installs, specifically managing the cache population (with a requirement that the cache and CRAN not be searched at the same time), or editing version numbers whose next values I do not control, but I would like to try for the simplest approach first. I know I'm not going to get a clean solution here, the relative weights of "known-good" and "latest" are different depending on where you stand. Greg On Sun, 31 Mar 2024 at 22:43, Martin Morgan wrote: available.packages indicates that By default, the return value includes only packages whose version and OS requirements are met by the running version of R, and only gives information on the latest versions of packages. So all repositories are consulted and
Re: [R-pkg-devel] help diagnosing win-builder failures
On 18.03.2024 02:07, Ben Bolker wrote: I think I may actually have figured this out. The Matrix package is being updated to version 1.7.0 soon, with expected ABI breakage. This version is **already installed on win-builder/r-devel**, so the Matrix/TMB/glmmTMB binary stack fails (digging into the logs a bit deeper showed that the *first* instance of a call to glmmTMB in any example/test/prior was failing ...) I think the only way to solve this is to bump/re-install the version of TMB that lives on win-builder. For the record, this will probably bite any package that depends on Matrix ABI ... This is only in the on demand check queue (not the daily CRAN repository checks nor the incoming checks) due to a recently checked Matrix in that queue (that would be auto-removed soon, but I'll trigger this manually now). Best, Uwe Ligges On 2024-03-17 4:42 p.m., Ivan Krylov wrote: Hi, This may need the help of Uwe Ligges to diagnose. I suspect this may be related to the Windows machine having too much memory committed (as Uwe has been able to pinpoint recently [*] about a package that failed to compile some heavily templated C++), but there is not enough information to give a conclusive diagnosis. On Sun, 17 Mar 2024 14:01:33 -0400 Ben Bolker wrote: 2. an ERROR running tests, where the output ends with a cryptic Anova: .. (please try to refrain from snarky comments about not using testthat ...) Pardon my ignorance, but is it an option to upload a version of the package that uses test_check(pkg, reporter=LocationReporter()) instead of the summary reporter? I don't know, could be worth a try. cheers Ben Bolker __ 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] M1mac check logs
Unfortunately, due to a temporary bug in R-devel, the check result changed before you looked at it. Now foxed and back to the older state where the check.log was sufficient to see the issue. Best, Uwe Ligges On 11.03.2024 17:09, Maciej Nasinski wrote: Hey All, I want to help fix the M1mac-related issue. The URL to issue is https://www.stats.ox.ac.uk/pub/bdr/M1mac/teal.reporter.out I am one of the coauthors of the teal reporter package. The question is how I can access ‘/Users/ripley/R/packages/tests-devel/teal.reporter.Rcheck/00install.out’ and ‘/Users/ripley/R/packages/tests-devel/teal.reporter.Rcheck/00check.log’ log files. I appreciate your help. KR Maciej Nasinski [[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
Re: [R-pkg-devel] R CHECK warning about new S3 generic/method consistency
On 11.03.2024 19:34, CRAN.r wrote: No, your assumption is backwards. The methods do need to include all arguments of the generic. As Writing R Extensions says near the start of section 7, "A method must have all the arguments of the generic, including … if the generic does." That's embarrassing. I was worried it was something simple I missed. Thanks for pointing that out! __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel Even more embarassing given you seem to be Mr CRAN given your mail message's "From" field ... Uwe Ligges __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file
Suggested packages should be used conditionally. If available, use it, otherwise the code should fail gracefully. Best, Uwe Ligges On 05.03.2024 11:58, Yohann Foucher wrote: Dear R-Members, I just have submitted an update of the ‘survivalSL' package because the last version depends on the ‘survivalmodels’ package, which has been recently archived. In the DESCRIPTION file of the new version 0.93 of the ‘survivalSL' package, I've moved ‘survivalmodels' from "Depends" to the ‘Suggests'. I thought this would solve the problem. Indeed, the 'survivalSL’ package can function without the ‘survivalmodels’ package if the user does not include the related learner (survival neural network) in the learning ensemble. Nevertheless, the new version 0.93 was archived again. I’m working on the estimation of a survival neural network without the ‘survivalmodels’ package but this developments will take a long time. During this period, do you have any idea to avoid the archiving of my package? Thank you for your help. Yohann __ 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] CRAN checks for release of a package with new vignette engine
OK, can you pls submit that one to CRAN again?
Best,
Uwe Ligges
On 04.03.2024 16:53, Christophe Dervieux wrote:
Hi,
yes I have defined in DESCRIPTION
VignetteBuilder:
quarto
and running `tools:::loadVignetteBuilder` on the package source
directory reads it correctly.
> tools:::loadVignetteBuilder(".")
[1] "quarto" "utils"
Best regards,
Christophe
On Mon, Mar 4, 2024 at 4:40 PM Uwe Ligges
wrote:
So you have defined
VignetteBuilder: quarto
??
Best,
Uwe
On 26.02.2024 21:28, Jeroen Ooms wrote:
On Mon, Feb 26, 2024 at 5:50 PM Christophe Dervieux wrote:
Hi,
I am trying to release a new version of the quarto R package. This new
version is adding support for a new vignette engine that will use quarto
CLI (https://quarto.org) when available. The vignettes inside the package
itself are '.qmd' files built with quarto.
While developing the feature, I noticed that R CMD check will query for
vignette engines information, and it will find engine in already installed
package (with `tools:::vignetteEngine`). So a package adding a new engine,
and using this engine for its vignette only works when the package is
installed before check.
This looks similar to https://bugs.r-project.org/show_bug.cgi?id=18191
Based on what I can see from the public cran incoming files [1,2], I
suspect the Debian check is loading the CRAN version of quarto (1.3),
rather than the one being checked (1.4), to test vignettes. As a
result it does not recognize the new qmd type vignettes introduced in
this version.
If this is indeed the case, the problem will resolve itself once the
submission is approved.
[1] https://cran.r-project.org/incoming/archive/quarto_1.4.tar.gz
[2]
https://win-builder.r-project.org/incoming_pretest/quarto_1.4_20240221_175256/
__
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] CRAN checks for release of a package with new vignette engine
So you have defined VignetteBuilder: quarto ?? Best, Uwe On 26.02.2024 21:28, Jeroen Ooms wrote: On Mon, Feb 26, 2024 at 5:50 PM Christophe Dervieux wrote: Hi, I am trying to release a new version of the quarto R package. This new version is adding support for a new vignette engine that will use quarto CLI (https://quarto.org) when available. The vignettes inside the package itself are '.qmd' files built with quarto. While developing the feature, I noticed that R CMD check will query for vignette engines information, and it will find engine in already installed package (with `tools:::vignetteEngine`). So a package adding a new engine, and using this engine for its vignette only works when the package is installed before check. This looks similar to https://bugs.r-project.org/show_bug.cgi?id=18191 Based on what I can see from the public cran incoming files [1,2], I suspect the Debian check is loading the CRAN version of quarto (1.3), rather than the one being checked (1.4), to test vignettes. As a result it does not recognize the new qmd type vignettes introduced in this version. If this is indeed the case, the problem will resolve itself once the submission is approved. [1] https://cran.r-project.org/incoming/archive/quarto_1.4.tar.gz [2] https://win-builder.r-project.org/incoming_pretest/quarto_1.4_20240221_175256/ __ 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 version on CRAN not up-to-date.
There is one Uwe Ligges but > 2 packages. On 12.02.2024 20:52, Rolf Turner wrote: On 20 January I submitted a revised version of my eglhmm package, to CRAN. I very rapidly got an email, emanating from Uwe Ligges' address, saying: Dear maintainer, thanks, package eglhmm_0.1-2.tar.gz is on its way to CRAN. Best regards, CRAN teams' auto-check service However the version of eglhmm that is available from CRAN is still 0.1-1. I have twice sent emails to Uwe Ligges (on 8 Feb. and 11 Feb.) asking why this was so. I CC-ed these emails to cran-submissi...@r-project.org . I have been met with complete radio silence. Can anyone suggest an explanation for this phenomenon? (I *hate* being ignored! ️ ) cheers, Rolf Turner __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN uses an old version of clang
Your users may also use old versions of clang. Hence please correct it. CRAN is also checking with the clang18 release candidate. Best, Uwe Ligges On 09.02.2024 15:59, Marcin Jurek wrote: Dear community, I recently submitted an update to my package. It previous version relied on Boost for Bessel and gamma functions but a colleague pointed out to me that they are included in the standard library beginning with the C++17 standard. I don't have access to a Mac so I tested my package on Rhub and on my local Linux and everything ran fine. However, it seems like CRAN is using an old version of Clang (14.03 vs 16 being the newest one) and it complained about these Bessel functions. I'm pasting the installation log below. I wonder if this is something I could hope to explain in cran-comments and have my package accepted as is? I could also revert to using Boost although I only need it for these special functions and things are much cleaner without it. In addition, one of the main reasons for this update was related to some warnings Boost started throwing. Really appreciate the help! * installing *source* package ‘GPvecchia’ ... ** package ‘GPvecchia’ successfully unpacked and MD5 sums checked ** using staged installation ** libs using C++ compiler: ‘Apple clang version 14.0.3 (clang-1403.0.22.14.1)’ using C++17 using SDK: ‘MacOSX11.3.sdk’ clang++ -arch x86_64 -std=gnu++17 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/Rcpp/include' -I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/RcppArmadillo/include' -I/opt/R/x86_64/include -fPIC -falign-functions=64 -Wall -g -O2 -c Esqe.cpp -o Esqe.o clang++ -arch x86_64 -std=gnu++17 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/Rcpp/include' -I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/RcppArmadillo/include' -I/opt/R/x86_64/include -fPIC -falign-functions=64 -Wall -g -O2 -c Matern.cpp -o Matern.o clang++ -arch x86_64 -std=gnu++17 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/Rcpp/include' -I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/RcppArmadillo/include' -I/opt/R/x86_64/include -fPIC -falign-functions=64 -Wall -g -O2 -c MaxMin.cpp -o MaxMin.o clang++ -arch x86_64 -std=gnu++17 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/Rcpp/include' -I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/RcppArmadillo/include' -I/opt/R/x86_64/include -fPIC -falign-functions=64 -Wall -g -O2 -c RcppExports.cpp -o RcppExports.o clang++ -arch x86_64 -std=gnu++17 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/Rcpp/include' -I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/RcppArmadillo/include' -I/opt/R/x86_64/include -fPIC -falign-functions=64 -Wall -g -O2 -c U_NZentries.cpp -o U_NZentries.o clang++ -arch x86_64 -std=gnu++17 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/Rcpp/include' -I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/RcppArmadillo/include' -I/opt/R/x86_64/include -fPIC -falign-functions=64 -Wall -g -O2 -c dist.cpp -o dist.o clang++ -arch x86_64 -std=gnu++17 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/Rcpp/include' -I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/RcppArmadillo/include' -I/opt/R/x86_64/include -fPIC -falign-functions=64 -Wall -g -O2 -c fastTree.cpp -o fastTree.o Matern.cpp:80:68: error: no member named 'cyl_bessel_k' in namespace 'std' covmat(j1,j2) = normcon*pow( scaledist, covparms(2) )*std::cyl_bessel_k(covparms(2),scaledist); //Rf_bessel_k(scaledist,covparms(2),1.0); ~^ 1 error generated. make: *** [Matern.o] Error 1 make: *** Waiting for unfinished jobs ERROR: compilation failed for package ‘GPvecchia’ * removing ‘/Volumes/Builds/packages/big-sur-x86_64/results/4.3/GPvecchia.Rcheck/GPvecchia’ [[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
Re: [R-pkg-devel] Winbuilder down?
Dear Naras, the queues are empty, so everything has been processed. Which package are you talking about? Then I can take a look what went wrong. Best, Uwe On 01.02.2024 15:53, Balasubramanian Narasimhan wrote: Just FYI: Winbuilder seems to be unresponsive. My uploads over the last 2 days have not resulted in any output or messages. Thank you. -Naras __ 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] Bioconductor reverse dependency checks for a CRAN package
For the BioC installation: For all CAN work, I simply use install.packages() after adding/setting the BioC repo/mirror which perfectly well resolves the dependencies. Best, Uwe Ligges On 30.01.2024 16:56, Ivan Krylov via R-package-devel wrote: Hello R-package-devel, What would you recommend in order to run reverse dependency checks for a package with 182 direct strong dependencies from CRAN and 66 from Bioconductor (plus 3 more from annotations and experiments)? Without extra environment variables, R CMD check requires the Suggested packages to be available, which means installing... revdepdep <- package_dependencies(revdep, which = 'most') revdeprest <- package_dependencies( unique(unlist(revdepdep)), which = 'strong', recursive = TRUE ) length(setdiff( unlist(c(revdepdep, revdeprest)), unlist(standard_package_names()) )) ...up to 1316 packages. 7 of these suggested packages aren't on CRAN or Bioconductor (because they've been archived or have always lived on GitHub), but even if I filter those out, it's not easy. Some of the Bioconductor dependencies are large; I now have multiple gigabytes of genome fragments and mass spectra, but also a 500-megabyte arrow.so in my library. As long as a data package declares a dependency on your package, it still has to be installed and checked, right? Manually installing the SystemRequirements is no fun at all, so I've tried the rocker/r2u container. It got me most of the way there, but there were a few remaining packages with newer versions on CRAN. For these, I had to install the system packages manually in order to build them from source. Someone told me to try the rocker/r-base container together with pak. It was more proactive at telling me about dependency conflicts and would have got me most of the way there too, except it somehow got me a 'stringi' binary without the corresponding libicu*.so*, which stopped the installation process. Again, nothing that a bit of manual work wouldn't fix, but I don't feel comfortable setting this up on a CI system. (Not on every commit, of course - that would be extremely wasteful - but it would be nice if it was possible to run these checks before release on a different computer and spot more problems this way.) I can't help but notice that neither install.packages() nor pak() is the recommended way to install Bioconductor packages. Could that introduce additional problems with checking the reverse dependencies? Then there's the check_packages_in_dir() function itself. Its behaviour about the reverse dependencies is not very helpful: they are removed altogether or at least moved away. Something may be wrong with my CRAN mirror, because some of the downloaded reverse dependencies come out with a size of zero and subsequently fail the check very quickly. I am thinking of keeping a separate persistent library with all the 1316 dependencies required to check the reverse dependencies and a persistent directory with the reverse dependencies themselves. Instead of using the reverse=... argument, I'm thinking of using the following scheme: 1. Use package_dependencies() to determine the list of packages to test. 2. Use download.packages() to download the latest version of everything if it doesn't already exist. Retry if got zero-sized or otherwise damaged tarballs. Remove old versions of packages if a newer version exists. 3. Run check_packages_in_dir() on the whole directory with the downloaded reverse dependencies. For this to work, I need a way to run step (3) twice, ensuring that one of the runs is performed with the CRAN version of the package in the library and the other one is performed with the to-be-released version of the package in the library. Has anyone already come up with an automated way to do that? No wonder nobody wants to maintain the XML package. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] new maintainer for CRAN package XML
On 23.01.2024 01:03, Lluís Revilla wrote: Dear Uwe and the CRAN team, Many thanks for maintaining the package for so long (>10 years!). I see the latest changes are in some internal C code related to updating the libxml2 library. In CRAN's experience, is this the highest time consuming task? Yes, and adapting the code to new compilers/toolchains. Note that the team only fixes urgent check issues. I have some questions about how the maintenance transfer will go: Would someone from the CRAN team help/review the new maintainer for some time? Or would there be a change in the "cre" role and that's all the further involvement of the CRAN team with the package (besides the excellent checks on CRAN)? Ideally the latter. Best, Uwe Ligges For anyone considering it, I analyzed a bit the situation of XML and RCurl: https://llrs.dev/post/2023/05/03/cran-maintained-packages/ In short, with ~300 direct dependencies, and many highly used, across CRAN and Bioconductor's packages. Kind regards, Lluís On Mon, 22 Jan 2024 at 15:51, Uwe Ligges wrote: Dear package developers, the CRAN team (and Professor Ripley in particular) has been the defacto maintainer of CRAN package 'XML'. Our hope was that maintainers of packages depending on XML will migrate to other packages for reading XML structures. This has not happened and we still see dozens of strong dependencies on XML. So we are looking for a person volunteering to take over 'XML'. Please let us know if you are interested. For the CRAN team, Uwe Ligges __ 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] new maintainer for CRAN package XML
On 24.01.2024 15:59, Jeroen Ooms wrote: On Mon, Jan 22, 2024 at 3:51 PM Uwe Ligges wrote: Dear package developers, the CRAN team (and Professor Ripley in particular) has been the defacto maintainer of CRAN package 'XML'. Our hope was that maintainers of packages depending on XML will migrate to other packages for reading XML structures. This has not happened and we still see dozens of strong dependencies on XML. How is this hope communicated? Many R users assume that XML package is in great shape and the preferable choice because it is maintained by the CRAN team and r-core members. Perhaps one could follow the precedent from the rgdal retirement, and set a deadline. One way to communicate this effectively would be by introducing a formal deprecation field in the package description. This could then be displayed on the XML CRAN html page, and when loading the package interactively. Other packages that import such a deprecated package could be given a CMD check warning. Sure, the new maintainer may do all these things. Best, Uwe Ligges __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] new maintainer for CRAN package XML
On 24.01.2024 16:38, Emmanuel Blondel wrote: if XML is deprecated, then what would be the choice for a package maintainer? Move to xml2 probably at some point I assume I use XML in the R packages I've been developing. For some of them, I started before CRAN started being the maintainer, and before xml2 inception. The thing is that XML fulfills requirements, it works and fulfills needs of depending packages that made the choice to use it. For this, it deserves to be maintained in CRAN, without having to enter into comparison exercices with other packages that , as of today, may be better to rely on (with certainly very good reasons). Moving to xml2 (or whatever other package), which although I could agree on the principle, can be costly for packages that use extensively XML. Doing so would mean that we first get the assurance that all XML features are covered elsewhere, and can be migrated smoothly. In any case, please acknowledge that this kind of migration may take time and require resources that vary (or even are missing) depending on the package projects. I doubt having CRAN setting a common deadline for retirement is a good way to foster an efficient maintenance of R packages depending on XML. It would be good to receive guidance how to migrate, while ensuring backward compatibility on our package features. We learned that it is hard to fade out XML support, and CRAN took over maintainance as XML had too many reverse dependencies. CRAN certainly does not have the resources to be able to deprecate XML in the same way as Roger Bivand did for rgdal. So now we are looking for a new maintainer on a public list, feel free to raise your hand and take over. Then you could even consider to deprecate it and help other maintainers to migrate. I won't spend more time on any discussions. We are just looking for a volunteer. Best, Uwe Ligges Best Le 24/01/2024 à 15:59, Jeroen Ooms a écrit : On Mon, Jan 22, 2024 at 3:51 PM Uwe Ligges wrote: Dear package developers, the CRAN team (and Professor Ripley in particular) has been the defacto maintainer of CRAN package 'XML'. Our hope was that maintainers of packages depending on XML will migrate to other packages for reading XML structures. This has not happened and we still see dozens of strong dependencies on XML. How is this hope communicated? Many R users assume that XML package is in great shape and the preferable choice because it is maintained by the CRAN team and r-core members. Perhaps one could follow the precedent from the rgdal retirement, and set a deadline. One way to communicate this effectively would be by introducing a formal deprecation field in the package description. This could then be displayed on the XML CRAN html page, and when loading the package interactively. Other packages that import such a deprecated package could be given a CMD check warning. __ 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-pkg-devel] new maintainer for CRAN package XML
Dear package developers, the CRAN team (and Professor Ripley in particular) has been the defacto maintainer of CRAN package 'XML'. Our hope was that maintainers of packages depending on XML will migrate to other packages for reading XML structures. This has not happened and we still see dozens of strong dependencies on XML. So we are looking for a person volunteering to take over 'XML'. Please let us know if you are interested. For the CRAN team, Uwe Ligges __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] New Package Removal because Shared Library Too Large from Debugging Symbols
Others have pointed you to the Additional issue, namely LTO. But I really cannot resist: You omitted a line from our message that actually explains it. We wrote: "Do remember to look at the 'Additional issues'." Best, Uwe Ligges On 20.01.2024 20:38, Johann Gaebler wrote: Hi everyone, I received the following message regarding `rar` <https://cran.r-project.org/package=rar>, a package that I put up on CRAN two days ago: Dear maintainer, Please see the problems shown on <https://cran.r-project.org/web/checks/check_results_rar.html>. Please correct before 2024-02-02 to safely retain your package on CRAN. The issue is that the compiled libraries are too large. The Mac CRAN checks turned up the following note: installed size is 8.9Mb sub-directories of 1Mb or more: libs 8.7Mb I have not been able to reproduce the issue either locally or on any machine I have ready access to. I have built it on some of the Rhub and R-Project build systems, and the same issue (with very different `libs` sizes) came up on some of them: • (RHub) Ubuntu Linux 20.04.1 LTS, R-release, GCC: 18.2Mb, • (RHub) Fedora Linux, R-devel, clang, gfortran: 6.8Mb, • (R-Project) r-release-macosx-arm64: 8.5Mb. Based on trying to read up about this, it seems that this is a pretty common problem <http://dirk.eddelbuettel.com/blog/2017/08/14/#009_compact_shared_libraries> for compiled packages because of debugging symbols getting inserted into the shared library file. Using the fix from that blog post where you modify the Makevars to strip debugging symbols from the shared library seems to solve the issue on those build systems, so I feel reasonably confident that this is what’s going on. Apparently many, many existing packages on CRAN have the same issue. However, I’m very new to R package development, so I’m not exactly sure what to do. I have two questions: 1. Is there anything I need to “fix” here, or should I just make contact with the CRAN folks and bring the fact that this is being caused by debugging symbols to their attention? 2. Regardless of whether or not I have to fix this issue for CRAN, is there a way to strip out the debugging symbols that comports with CRAN policies? The method suggested in the blog post above (adding a phony target in `Makevars` that strips the shared library) seems not to be CRAN-compliant, but I could be mistaken about that. (In particular, I had to modify it locally to get it to run, so I’m not sure what the platform-independent version of it looks like.) Thanks in advance for the help! Sincerely, Johann D. Gaebler [[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
Re: [R-pkg-devel] CMake on CRAN Systems
On 17.01.2024 08:59, Matthias Gondan wrote: For package rswipl, cmake still seems to work, but * one has to search for it on MacOS, see the src/Makevars, as well as the relevant sections in Writing R extensions * Windows Defender (also on CRAN) complains about dubious exe-files when checking the "endianness" of the target system. That can be circumvented by telling cmake to compile static libraries instead of executables. Indeed, currently Windows Defender gives false positives for some temprary .exe files that CMake creates. As thge filenames and locations are random, there is no straightforward way to tell the defender about exceptions. Hence please follow the advice and tell cmake to compile static libraries instead of executables (an excellent idea, thanks!). [Microsoft knows about this for several weeks now without action.] Best, Uwe Ligges I am unsure if my response is specific to your problem, but the links below do not seem to work. Gesendet: Mittwoch, den 17.01.2024 um 08:37 Uhr Von: "Sameh Abdulah" An: "R Package Development" Betreff: [R-pkg-devel] CMake on CRAN Systems Hi All, We recently encountered an installation issue with our package on CRAN. We've been depending on CMake, assuming it is readily available by default, but it appears to be only available on the M1mac system but not on the others. Should we include the CMake installation within our package? We encountered another issue with OpenMP, but we managed to resolve it by consulting the manual. https://urldefense.com/v3/__https://cran-archive.r-project.org/web/checks/2024/2024-01-12_check_results_MPCR.html__;!!Nmw4Hv0!1cg5mCeLOB9fBslqbEGB1S0_MEcOLMjk6m4hpfWDyXErAlWtm82xz9ZUU3aQ3q6jkXZBM2tNhUp3EI3JmigE4EvCLlrC$<https://urldefense.com/v3/__https:/cran-archive.r-project.org/web/checks/2024/2024-01-12_check_results_MPCR.html__;!!Nmw4Hv0!1cg5mCeLOB9fBslqbEGB1S0_MEcOLMjk6m4hpfWDyXErAlWtm82xz9ZUU3aQ3q6jkXZBM2tNhUp3EI3JmigE4EvCLlrC$> Best, --Sameh -- This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email. [[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 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] checking CRAN incoming feasibility
On 16.01.2024 06:49, Rolf Turner wrote: On Tue, 16 Jan 2024 16:24:59 +1100 Hugh Parsonage wrote: Surely the software just has to check that there is web connection to a CRAN mirror. Nope! The full code is in tools:::.check_package_CRAN_incoming (the body of which filled up my entire console), but to name a few checks it has to do: check that the name of the package is not the same as any other, including archived packages (which means that it has to download the package metadata), make sure the licence is ok, see if the version number is ok. 10 minutes is quite a lot though. I suspect the initial connection may have been faulty. Well, it may not have been 10 minutes, but it was at least 5. The problem is persistent/repeatable. I don't believe that there is any faulty connection. Thanks for the insight. cheers, Rolf Turner I'd suggest to choose a local CRAN mirror for the checks (particularly as you are located at the most opposite side of the world from Vienna) which may help if several requests to CRAN are done. Also, you may want to disable the URL checks, which also take some time for us, but may be way more serious if you point to many URLs that do not resolve to servers in your part of the world. Best, Uwe Ligges __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Does dependencies up to date on the pretest CRAN infrastructure
On 13.01.2024 15:01, Uwe Ligges wrote:
Fascinating, now it worked with the latest winbuilder submission 3 times
in a row when I checked it manually. So maybe Ivan was right and there
was a very demanding set of other packages compiling at the same time?
I don't know.
Serge, Can you somply submit your latest winbuilder upload to CRAN?
Really, I inspected some more. The underlying issue is simple:
The C++ compiler used under Windows asks for precomitted memory. If
several processes are running at the same time, a lot of memory is
precomitted. And Windows does not use it for other processes, even if
almost nothing is actually used.
So while the used memory may be around 50GB, all of the rest (of 756 GB
including swap space) may have been precomitted (but unused) and new
processes failed to start correctly. G.
Best,
Uwe Ligges
Best,
Uwe Ligges
On 13.01.2024 14:12, Uwe Ligges wrote:
I can take a look, but not sure if I get to it before monday.
I haven't seen it for any other packages recently.
My suspicion is currently a strange mix of cmd.exe and sh.exe calls.
But this is a very wild guess.
Best,
Uwe
On 13.01.2024 14:08, Uwe Ligges wrote:
On 13.01.2024 10:10, Ivan Krylov via R-package-devel wrote:
В Fri, 12 Jan 2024 21:19:00 +0100
Serge пишет:
After somme minor midficiations, I make a try on the winbuilder site.
I was able to build the archive with the static library
but I get again a Bad address error. You can have a look to
https://win-builder.r-project.org/bw47qsMX3HTd/00install.out
I think that Win-Builder is running out of memory. It took some
experimenting, but I was able to reproduce something like this using
the following:
1. Set the swap file in the Windows settings to minimal recommended
size and disable its automatic growth
2. Write and run a program that does malloc(LARGE_NUMBER); getchar();
so that almost all physical memory is allocated
3. Run gcc -DFOO=`/path/to/Rscript -e 'some script'` & many times
I got a lot of interesting errors, including the "Bad address":
Warnings:
1: .getGeneric(f, , package) : internal error -4 in R_decompress1
2: package "methods" in options("defaultPackages") was not found
0 [main] bash (2892) child_copy: cygheap read copy failed,
0x0..0x800025420, done 0, windows pid 2892, Win32 error 299
0 [main] bash (3256) C:\rtools43\usr\bin\bash.exe: *** fatal error in
forked process - MEM_COMMIT failed, Win32 error 1455
-bash: fork: retry: Resource temporarily unavailable
-bash: R-devel/bin/Rscript.exe: Bad address
The above indeed happens if not sufficient memory would be available.
Important to know: This includes unused but committed memory which
may be a lot.
But I doubt it is the case on winbuilder as the machines has 256GB or
more (depending in the machine) and additionally 500GB swap space on
SSD.
Best,
Uwe
Your package is written in C++, but that by itself shouldn't disqualify
it. On my Linux computer, /usr/bin/time R -e
'install.packages("MixAll")' says that the installation takes slightly
less than a gigabyte of memory ("912516maxresident k"), which is par
the course for such packages. (My small Rcpp-using package takes
approximately half a gigabyte by the same metric.)
I'm still not 100% sure (if Win-Builder is running out of memory, why
are you seeing "Bad address" only and not the rest of the carnage?),
but I'm not seeing a problem with your package, either. If EFAULT is
Cygwin's way of saying "I caught a bad pointer in your system call"
(which, I must stress, is happening inside /bin/sh, not your package
or even R at all), it's not impossible that Win-Builder is having
hardware problems. Unfortunately, they take a lot of effort and
downtime to diagnose and could be hiding anywhere from RAM to the power
supply.
__
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
Re: [R-pkg-devel] Does dependencies up to date on the pretest CRAN infrastructure
Fascinating, now it worked with the latest winbuilder submission 3 times
in a row when I checked it manually. So maybe Ivan was right and there
was a very demanding set of other packages compiling at the same time?
I don't know.
Serge, Can you somply submit your latest winbuilder upload to CRAN?
Best,
Uwe Ligges
On 13.01.2024 14:12, Uwe Ligges wrote:
I can take a look, but not sure if I get to it before monday.
I haven't seen it for any other packages recently.
My suspicion is currently a strange mix of cmd.exe and sh.exe calls. But
this is a very wild guess.
Best,
Uwe
On 13.01.2024 14:08, Uwe Ligges wrote:
On 13.01.2024 10:10, Ivan Krylov via R-package-devel wrote:
В Fri, 12 Jan 2024 21:19:00 +0100
Serge пишет:
After somme minor midficiations, I make a try on the winbuilder site.
I was able to build the archive with the static library
but I get again a Bad address error. You can have a look to
https://win-builder.r-project.org/bw47qsMX3HTd/00install.out
I think that Win-Builder is running out of memory. It took some
experimenting, but I was able to reproduce something like this using
the following:
1. Set the swap file in the Windows settings to minimal recommended
size and disable its automatic growth
2. Write and run a program that does malloc(LARGE_NUMBER); getchar();
so that almost all physical memory is allocated
3. Run gcc -DFOO=`/path/to/Rscript -e 'some script'` & many times
I got a lot of interesting errors, including the "Bad address":
Warnings:
1: .getGeneric(f, , package) : internal error -4 in R_decompress1
2: package "methods" in options("defaultPackages") was not found
0 [main] bash (2892) child_copy: cygheap read copy failed,
0x0..0x800025420, done 0, windows pid 2892, Win32 error 299
0 [main] bash (3256) C:\rtools43\usr\bin\bash.exe: *** fatal error in
forked process - MEM_COMMIT failed, Win32 error 1455
-bash: fork: retry: Resource temporarily unavailable
-bash: R-devel/bin/Rscript.exe: Bad address
The above indeed happens if not sufficient memory would be available.
Important to know: This includes unused but committed memory which may
be a lot.
But I doubt it is the case on winbuilder as the machines has 256GB or
more (depending in the machine) and additionally 500GB swap space on SSD.
Best,
Uwe
Your package is written in C++, but that by itself shouldn't disqualify
it. On my Linux computer, /usr/bin/time R -e
'install.packages("MixAll")' says that the installation takes slightly
less than a gigabyte of memory ("912516maxresident k"), which is par
the course for such packages. (My small Rcpp-using package takes
approximately half a gigabyte by the same metric.)
I'm still not 100% sure (if Win-Builder is running out of memory, why
are you seeing "Bad address" only and not the rest of the carnage?),
but I'm not seeing a problem with your package, either. If EFAULT is
Cygwin's way of saying "I caught a bad pointer in your system call"
(which, I must stress, is happening inside /bin/sh, not your package
or even R at all), it's not impossible that Win-Builder is having
hardware problems. Unfortunately, they take a lot of effort and
downtime to diagnose and could be hiding anywhere from RAM to the power
supply.
__
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] Does dependencies up to date on the pretest CRAN infrastructure
I can take a look, but not sure if I get to it before monday.
I haven't seen it for any other packages recently.
My suspicion is currently a strange mix of cmd.exe and sh.exe calls. But
this is a very wild guess.
Best,
Uwe
On 13.01.2024 14:08, Uwe Ligges wrote:
On 13.01.2024 10:10, Ivan Krylov via R-package-devel wrote:
В Fri, 12 Jan 2024 21:19:00 +0100
Serge пишет:
After somme minor midficiations, I make a try on the winbuilder site.
I was able to build the archive with the static library
but I get again a Bad address error. You can have a look to
https://win-builder.r-project.org/bw47qsMX3HTd/00install.out
I think that Win-Builder is running out of memory. It took some
experimenting, but I was able to reproduce something like this using
the following:
1. Set the swap file in the Windows settings to minimal recommended
size and disable its automatic growth
2. Write and run a program that does malloc(LARGE_NUMBER); getchar();
so that almost all physical memory is allocated
3. Run gcc -DFOO=`/path/to/Rscript -e 'some script'` & many times
I got a lot of interesting errors, including the "Bad address":
Warnings:
1: .getGeneric(f, , package) : internal error -4 in R_decompress1
2: package "methods" in options("defaultPackages") was not found
0 [main] bash (2892) child_copy: cygheap read copy failed,
0x0..0x800025420, done 0, windows pid 2892, Win32 error 299
0 [main] bash (3256) C:\rtools43\usr\bin\bash.exe: *** fatal error in
forked process - MEM_COMMIT failed, Win32 error 1455
-bash: fork: retry: Resource temporarily unavailable
-bash: R-devel/bin/Rscript.exe: Bad address
The above indeed happens if not sufficient memory would be available.
Important to know: This includes unused but committed memory which may
be a lot.
But I doubt it is the case on winbuilder as the machines has 256GB or
more (depending in the machine) and additionally 500GB swap space on SSD.
Best,
Uwe
Your package is written in C++, but that by itself shouldn't disqualify
it. On my Linux computer, /usr/bin/time R -e
'install.packages("MixAll")' says that the installation takes slightly
less than a gigabyte of memory ("912516maxresident k"), which is par
the course for such packages. (My small Rcpp-using package takes
approximately half a gigabyte by the same metric.)
I'm still not 100% sure (if Win-Builder is running out of memory, why
are you seeing "Bad address" only and not the rest of the carnage?),
but I'm not seeing a problem with your package, either. If EFAULT is
Cygwin's way of saying "I caught a bad pointer in your system call"
(which, I must stress, is happening inside /bin/sh, not your package
or even R at all), it's not impossible that Win-Builder is having
hardware problems. Unfortunately, they take a lot of effort and
downtime to diagnose and could be hiding anywhere from RAM to the power
supply.
__
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] Does dependencies up to date on the pretest CRAN infrastructure
On 13.01.2024 10:10, Ivan Krylov via R-package-devel wrote:
В Fri, 12 Jan 2024 21:19:00 +0100
Serge пишет:
After somme minor midficiations, I make a try on the winbuilder site.
I was able to build the archive with the static library
but I get again a Bad address error. You can have a look to
https://win-builder.r-project.org/bw47qsMX3HTd/00install.out
I think that Win-Builder is running out of memory. It took some
experimenting, but I was able to reproduce something like this using
the following:
1. Set the swap file in the Windows settings to minimal recommended
size and disable its automatic growth
2. Write and run a program that does malloc(LARGE_NUMBER); getchar();
so that almost all physical memory is allocated
3. Run gcc -DFOO=`/path/to/Rscript -e 'some script'` & many times
I got a lot of interesting errors, including the "Bad address":
Warnings:
1: .getGeneric(f, , package) : internal error -4 in R_decompress1
2: package "methods" in options("defaultPackages") was not found
0 [main] bash (2892) child_copy: cygheap read copy failed,
0x0..0x800025420, done 0, windows pid 2892, Win32 error 299
0 [main] bash (3256) C:\rtools43\usr\bin\bash.exe: *** fatal error in
forked process - MEM_COMMIT failed, Win32 error 1455
-bash: fork: retry: Resource temporarily unavailable
-bash: R-devel/bin/Rscript.exe: Bad address
The above indeed happens if not sufficient memory would be available.
Important to know: This includes unused but committed memory which may
be a lot.
But I doubt it is the case on winbuilder as the machines has 256GB or
more (depending in the machine) and additionally 500GB swap space on SSD.
Best,
Uwe
Your package is written in C++, but that by itself shouldn't disqualify
it. On my Linux computer, /usr/bin/time R -e
'install.packages("MixAll")' says that the installation takes slightly
less than a gigabyte of memory ("912516maxresident k"), which is par
the course for such packages. (My small Rcpp-using package takes
approximately half a gigabyte by the same metric.)
I'm still not 100% sure (if Win-Builder is running out of memory, why
are you seeing "Bad address" only and not the rest of the carnage?),
but I'm not seeing a problem with your package, either. If EFAULT is
Cygwin's way of saying "I caught a bad pointer in your system call"
(which, I must stress, is happening inside /bin/sh, not your package
or even R at all), it's not impossible that Win-Builder is having
hardware problems. Unfortunately, they take a lot of effort and
downtime to diagnose and could be hiding anywhere from RAM to the power
supply.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Suggests with non-CRAN packages
On 10.01.2024 16:29, Josiah Parry wrote:
Well, I wouldn't say "obviously." It's not quite clear what a "standard"
CRAN-like repository looks like unless you have an intimate knowledge of
CRAN's structure.
A repository r that works with
install.packages(..., repos=r)
i.e. needs PACKAGES files and sources/binaries in relevant directories
such as
./src (at least)
and ideally also
./bin/windows/contrib/4.2/
./bin/windows/contrib/4.3/
./bin/windows/contrib/4.4/
and similarly for mac.
Best,
Uwe Ligges
Regardless, thank you for the feedback! I'll adjust the description file.
On Wed, Jan 10, 2024 at 10:26 AM Uwe Ligges
<mailto:lig...@statistik.tu-dortmund.de>> wrote:
On 10.01.2024 15:35, Josiah Parry wrote:
> Thanks, all. As it goes, the package submission failed. The
package that
> is suggested is available at https://r.esri.com/bin/
<https://r.esri.com/bin/>
> <https://r.esri.com/bin/ <https://r.esri.com/bin/>> and as such
provided `https://r.esri.com <https://r.esri.com>
> <https://r.esri.com <https://r.esri.com>>` as the url in
`Additional_repositories`.
There is no
https://r.esri.com/src <https://r.esri.com/src>
hence it is obviously not a standard repository.
> The request was to remove the additional repositories and provide
> instructions for package installation in the Description field. This
> package, arcgisbinding, is used in one line of the entire package
>
https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123
<https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123>
<https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123
<https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123>> to
extract an authorization token. It is provided for compatibility with a semi-closed-source R package. The installation
instructions for which arelengthy (https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html
<https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html>
<https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html
<https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html>>) and /only /available as a windows
binary. Providing an explicit call out for installation in the "Description" field of the DESCRIPTION feels like it
is co-opting the Description to describe the installation process for a function that I anticipate /very few /people to use.
So you can either remove the need for that package or say something
like
" and if an authorization token is to be extracted on Windows, the
'arcgisbinding' package is needed that can be installed as explained at
<https://r.esri.com <https://r.esri.com>>."
Best,
Uwe Ligges
>
> Is there another approach that can be taken here? The one requested
> feels like an incorrect use of the description field because it no
> longer describes the package but how to handle one very rare edge
case.
>
> On Wed, Jan 3, 2024 at 12:36 PM Uwe Ligges
> mailto:lig...@statistik.tu-dortmund.de>
> <mailto:lig...@statistik.tu-dortmund.de
<mailto:lig...@statistik.tu-dortmund.de>>> wrote:
>
> From the CRAN polcies:
>
> "Packages on which a CRAN package depends should be available
from a
> mainstream repository: if any mentioned in ‘Suggests’ or
‘Enhances’
> fields are not from such a repository, where to obtain them at a
> repository should be specified in an
‘Additional_repositories’ field of
> the DESCRIPTION file (as a comma-separated list of repository
URLs) or
> for other means of access, described in the ‘Description’
field. "
>
> Best,
> Uwe Ligges
>
>
>
>
> On 03.01.2024 18:19, Josiah Parry wrote:
> > Thanks, both. I'm not familiar with
Additional_repositories. Must
> the
> > package source be specified there? Or can it be specified via
> > documentation a la Rd file?
> >
> > On Wed, Jan 3, 2024 at 12:14 PM Uwe Ligges
> > mailto:lig...@statistik.tu-dortmund.de>
> <mailto:lig...@statistik.tu-dortmund.de
<mailto:lig...@statistik.tu-dortmund.de>>
> > <mailto:lig...@statistik.tu-dortmund.de
<mailto:lig...@statistik.tu-dortmund.de>
> &
Re: [R-pkg-devel] Suggests with non-CRAN packages
On 10.01.2024 15:35, Josiah Parry wrote:
Thanks, all. As it goes, the package submission failed. The package that
is suggested is available at https://r.esri.com/bin/
<https://r.esri.com/bin/> and as such provided `https://r.esri.com
<https://r.esri.com>` as the url in `Additional_repositories`.
There is no
https://r.esri.com/src
hence it is obviously not a standard repository.
The request was to remove the additional repositories and provide
instructions for package installation in the Description field. This
package, arcgisbinding, is used in one line of the entire package
https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123 <https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123> to extract an authorization token. It is provided for compatibility with a semi-closed-source R package. The installation instructions for which arelengthy (https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html <https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html>) and /only /available as a windows binary. Providing an explicit call out for installation in the "Description" field of the DESCRIPTION feels like it is co-opting the Description to describe the installation process for a function that I anticipate /very few /people to use.
So you can either remove the need for that package or say something like
" and if an authorization token is to be extracted on Windows, the
'arcgisbinding' package is needed that can be installed as explained at
<https://r.esri.com>."
Best,
Uwe Ligges
Is there another approach that can be taken here? The one requested
feels like an incorrect use of the description field because it no
longer describes the package but how to handle one very rare edge case.
On Wed, Jan 3, 2024 at 12:36 PM Uwe Ligges
<mailto:lig...@statistik.tu-dortmund.de>> wrote:
From the CRAN polcies:
"Packages on which a CRAN package depends should be available from a
mainstream repository: if any mentioned in ‘Suggests’ or ‘Enhances’
fields are not from such a repository, where to obtain them at a
repository should be specified in an ‘Additional_repositories’ field of
the DESCRIPTION file (as a comma-separated list of repository URLs) or
for other means of access, described in the ‘Description’ field. "
Best,
Uwe Ligges
On 03.01.2024 18:19, Josiah Parry wrote:
> Thanks, both. I'm not familiar with Additional_repositories. Must
the
> package source be specified there? Or can it be specified via
> documentation a la Rd file?
>
> On Wed, Jan 3, 2024 at 12:14 PM Uwe Ligges
> mailto:lig...@statistik.tu-dortmund.de>
> <mailto:lig...@statistik.tu-dortmund.de
<mailto:lig...@statistik.tu-dortmund.de>>> wrote:
>
>
>
> On 03.01.2024 17:58, Duncan Murdoch wrote:
> > On 03/01/2024 11:33 a.m., Josiah Parry wrote:
> >> I have a scenario where I have an exported function that
> requires the
> >> installation a package that *is not* available on CRAN.
The body
> of the
> >> function is generally:
> >>
> >> fx <- function() {
> >> rlang::check_installed("noncranpkg")
> >> noncranpkg::gx()
> >> }
> >>
> >> As required, this package is in the Suggests field. But this
> results in a
> >> note:
> >>
> >> checking package dependencies ... NOTE
> >> Package suggested but not available for checking:
‘noncranpkg’
> >>
> >> Can this be safely ignored?
> >
> > Uwe said yes, and he's an authority. But for your users, it
> might be
> > nice to include an Additional_repositories field so they
can find
> the
> > package. This needs to be organized as an actual
repository; the
> drat
> > package is a very convenient way to set one up.
>
> Thanks for elaborating, yes of course, people have to declare
where to
> get the package from. The note from above is still unavoidable in
> that case.
>
> Best,
> Uwe
>
> >
> > Duncan Murdoch
> >
> > __
> > R-package-devel@r-project.org
<mailto:R
Re: [R-pkg-devel] [Rd] static html vignette
On 04.01.2024 21:23, Duncan Murdoch wrote:
On 04/01/2024 11:43 a.m., Adrian Dușa wrote:
> (Moved here following Ivan's suggestion)
>
> On Thu, Jan 4, 2024 at 12:55 PM Ivan Krylov
wrote:
>
>> On Thu, 4 Jan 2024 11:57:15 +0200
>> Adrian Dușa wrote:
>>
>>> I wonder if it would be possible to include an html static vignette.
>>
>> I would say that static vignettes are against the spirit of vignettes:
>> the idea is to provide another layer of unit testing to the package by
>> providing a deeper executable example than is possible with just Rd
>> examples. I think that Bioconductor will even refuse a package with a
>> vignette with no executable code in it.
>>
>
> I understand that perfectly, but for instance my package declared
already
> has over 800 tests and 100% code coverage. More unit testing in the
> vignettes really strikes as unnecessary.
>
> One other reason to use a static vignette, in my case, is that package
> Sweave is not available for my version of R (on MacOS, M2 version)
As far as I know, there is no package called Sweave, there's just the
Sweave() function in the utils package.>
>
>
>> Still, you can ue the R.rsp package to provide static vignettes in
>> both PDF and HTML formats:
>>
>>
https://cran.r-project.org/package=R.rsp/vignettes/R_packages-Static_PDF_and_HTML_vignettes.pdf
>>
>> This will add 6 packages to your total Suggests budget:
>>
>> setdiff(
>> unlist(package_dependencies('R.rsp', recursive=TRUE)),
>> unlist(standard_package_names())
>> )
>> # [1] "R.methodsS3" "R.oo" "R.utils" "R.cache" "digest"
>
>
> Yes indeed, I know about R.rsp.
> To me at least, zero dependency means that users install that package
and
> that package alone, the reason for which I am now looking for static
> (preferably html) vignettes.
>
> I guess another question is why should the "Suggests" packages need
to be
> installed by end users. I understand CRAN checks need to make sure the
> Vignettes can be processed and the code inside runs fine (just like the
> examples in the Rd files) but it is very unlikely that end-users will
want
> to compile the vignettes themselves.
>
> From my own experience of almost 20 years of using R, I never-ever
build
> the vignettes of a certain package because it is much simpler to read
them
> on CRAN. I wonder, then, why are end users forced to install
> Vignette-building "Suggests" packages (with long dependency chains) when
> they practically never do that.
>
> Life would be much simpler if the Suggests packages would not be
> (automatically) installed, or if CRAN provided a way to include static
> Vignettes to avoid the heavy dependencies of building them.
>
Users aren't forced to install "Suggests" packages. That's a choice
they make. The default for `install.packages()` is `dependencies = NA`,
which says to install hard dependencies (Imports, Depends, LinkingTo).
Users have to choose a non-default setting to include Suggests.
Also note that the maintainer builds the vignette whe calling
R CMD build
CRAN checks whether the vignette can be build.
If a user installs a package, the already produced vignette (on the
maintainers machine by R CMD build) is instaled. There is no need for
the user to install any extra package for being able to look at the
vignettes.
Best,
Uwe Ligges
Duncan Murdoch
__
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] Suggests with non-CRAN packages
From the CRAN polcies:
"Packages on which a CRAN package depends should be available from a
mainstream repository: if any mentioned in ‘Suggests’ or ‘Enhances’
fields are not from such a repository, where to obtain them at a
repository should be specified in an ‘Additional_repositories’ field of
the DESCRIPTION file (as a comma-separated list of repository URLs) or
for other means of access, described in the ‘Description’ field. "
Best,
Uwe Ligges
On 03.01.2024 18:19, Josiah Parry wrote:
Thanks, both. I'm not familiar with Additional_repositories. Must the
package source be specified there? Or can it be specified via
documentation a la Rd file?
On Wed, Jan 3, 2024 at 12:14 PM Uwe Ligges
<mailto:lig...@statistik.tu-dortmund.de>> wrote:
On 03.01.2024 17:58, Duncan Murdoch wrote:
> On 03/01/2024 11:33 a.m., Josiah Parry wrote:
>> I have a scenario where I have an exported function that
requires the
>> installation a package that *is not* available on CRAN. The body
of the
>> function is generally:
>>
>> fx <- function() {
>> rlang::check_installed("noncranpkg")
>> noncranpkg::gx()
>> }
>>
>> As required, this package is in the Suggests field. But this
results in a
>> note:
>>
>> checking package dependencies ... NOTE
>> Package suggested but not available for checking: ‘noncranpkg’
>>
>> Can this be safely ignored?
>
> Uwe said yes, and he's an authority. But for your users, it
might be
> nice to include an Additional_repositories field so they can find
the
> package. This needs to be organized as an actual repository; the
drat
> package is a very convenient way to set one up.
Thanks for elaborating, yes of course, people have to declare where to
get the package from. The note from above is still unavoidable in
that case.
Best,
Uwe
>
> Duncan Murdoch
>
> __
> R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
<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] Suggests with non-CRAN packages
On 03.01.2024 17:58, Duncan Murdoch wrote:
On 03/01/2024 11:33 a.m., Josiah Parry wrote:
I have a scenario where I have an exported function that requires the
installation a package that *is not* available on CRAN. The body of the
function is generally:
fx <- function() {
rlang::check_installed("noncranpkg")
noncranpkg::gx()
}
As required, this package is in the Suggests field. But this results in a
note:
checking package dependencies ... NOTE
Package suggested but not available for checking: ‘noncranpkg’
Can this be safely ignored?
Uwe said yes, and he's an authority. But for your users, it might be
nice to include an Additional_repositories field so they can find the
package. This needs to be organized as an actual repository; the drat
package is a very convenient way to set one up.
Thanks for elaborating, yes of course, people have to declare where to
get the package from. The note from above is still unavoidable in that case.
Best,
Uwe
Duncan Murdoch
__
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] Suggests with non-CRAN packages
On 03.01.2024 17:33, Josiah Parry wrote:
I have a scenario where I have an exported function that requires the
installation a package that *is not* available on CRAN. The body of the
function is generally:
fx <- function() {
rlang::check_installed("noncranpkg")
noncranpkg::gx()
}
As required, this package is in the Suggests field. But this results in a
note:
checking package dependencies ... NOTE
Package suggested but not available for checking: ‘noncranpkg’
Can this be safely ignored?
Yes.
Best,
Uwe Ligges
[[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
Re: [R-pkg-devel] CRAN submission struggle
On 29.12.2023 09:13, Greg Hunt wrote:
Christaan,
The elapsed time note is because CRAN expects that examples will be
configured to run single threaded and some package that you use, or a
package used by a package that you use is multi-threading by default and
using more CPU time than clock time. If you cannot figure out how to
reconfigure the multi-threaded package, a number of people have found that
the simplest thing to do is disable running the example (which reduces the
effective test coverage provided by the example).
No and no:
1.
user system elapsed
IOPS 10.06 3.35 35.04
suggests that either the machines this ran on is heavily loaded (so that
elapsed >> user) or something is waiting like some internet access. [For
multithreading it would be user > elapsed.]
2. The solution is not to exclude examples ebtirely, as we need runtime
checks.
For internet access: Set a timeout and let the exampe fail gracefully in
case web access takes more than, e.g., 2. sec.
In general: Please reduce each example to less than 5 sec.
So use small toy examples. If you really want to add rel world examples
that may take longer, then add them in addition to toy examples and wrap
in \donttest{}.
Best,
Uwe Ligges
I haven’t encountered the miktex exception file before but i suspect its a
side effect of a miktex error. Packages should not leave files behind in
the temp directory. If you expect a miktex error you need to remove the
file. If you don’t you need to track down and fix or work around the bug.
The build process is really a quality check on your package.
Greg
On Fri, 29 Dec 2023 at 3:01 am, Christiaan Pieterse <
pietie.cjp.1...@gmail.com> wrote:
Hi,
Thank you for showing the difference in the ExampleTradeData. I've fixed
this by adding a .Gitignore file and a "data-raw" folder to load the
ExampleTradeData. I hope I did this correctly. When I check the package (
https://github.com/WoutersResearchGroup/R-IO-PS/tree/CRAN-prep) in
RStudio.
I only get 3 notes (see below), and if I run it in PositCloud, it crashes
or yields the same 1 ERROR and 2 NOTES result as before. Why might this be?
Is it a problem or is it fine if I continue working in RStudio since I
cannot increase the specs in PositCloud because I'm working on a research
group account?
Here are the 3 notes I receive in RStudio:
The first is the expected New Submission Note.
The second is the runtime that is too long:
* checking examples ... [43s] NOTE
Examples with CPU (user + system) or elapsed time > 5s
user system elapsed
IOPS 10.06 3.35 35.04
How can I reduce this time? I'm not sure how to reduce the size of my
ExampleTradeData without the check giving errors when running the example.
The third note I am unsure what it means:
* checking for detritus in the temp directory ... NOTE
Found the following files/directories:
'lastMiKTeXException'
Kind regards
Christiaan
On Thu, 28 Dec 2023 at 15:55, Ivan Krylov wrote:
Hi Christiaan,
В Thu, 28 Dec 2023 14:57:55 +0200
Christiaan Pieterse пишет:
Still, I couldn't figure out why I ran into this problem, so I
created a test file called "Test Example.R" (available at the same
GitHub repository:
https://github.com/WoutersResearchGroup/R-IO-PS/tree/CRAN-prep).
I see you're always adding or updating files to the GitHub repo by
means of uploading. While that's certainly one way to use GitHub, it's
combines the least convenient aspects of two approaches to using GitHub.
With GitHub purely in the browser, GitHub is just a website where you
keep and edit code, running nothing else on the local computer. Code
can be run in Codespaces or using GitHub Actions. Microsoft will want
to be paid money to run code on their computers.
With GitHub as a Git remote, there is a local checkout [*] that's kept
in sync with GitHub by means of commits [**] and pushes [***], letting
you create meaningful, describable snapshots of changes in your code
spanning multiple files at the same time.
Right now, it probably feels like Dropbox but worse.
This file creates the function in the global environment (note that
this is the same function code as available in the package
"R/iopspackage2.0.R" file), and then runs this function with the same
example as in the package (If you want to try this yourself, just
load the data/ExampleTradeData.rda in before running the Test Example
file). This test file yields no errors when I run it and produces the
correct results. When I then proceed to build and check the package,
it yields the same example error as before. I do not understand why
or what could cause this issue.
The difference is in the ExampleTradeData variable, which "Test
Example.R" doesn't define.
With data(ExampleTradeData), the script works.
With ExampleTradeData <-
read.csv(system.file("extdata","ExampleTradeData.csv",package="iopspackage")),
the script fails ex
Re: [R-pkg-devel] CRAN submission struggle
On 28.12.2023 17:00, Christiaan Pieterse wrote:
Hi,
Thank you for showing the difference in the ExampleTradeData. I've fixed
this by adding a .Gitignore file and a "data-raw" folder to load the
ExampleTradeData. I hope I did this correctly. When I check the package (
https://github.com/WoutersResearchGroup/R-IO-PS/tree/CRAN-prep) in RStudio.
I only get 3 notes (see below), and if I run it in PositCloud, it crashes
or yields the same 1 ERROR and 2 NOTES result as before. Why might this be?
Is it a problem or is it fine if I continue working in RStudio since I
cannot increase the specs in PositCloud because I'm working on a research
group account?
Here are the 3 notes I receive in RStudio:
The first is the expected New Submission Note.
The second is the runtime that is too long:
* checking examples ... [43s] NOTE
Examples with CPU (user + system) or elapsed time > 5s
user system elapsed
IOPS 10.06 3.35 35.04
How can I reduce this time? I'm not sure how to reduce the size of my
ExampleTradeData without the check giving errors when running the example.
Use a subset of the data or less iterations?
If this fails for you, then we need code to reproduce...
The third note I am unsure what it means:
* checking for detritus in the temp directory ... NOTE
Found the following files/directories:
'lastMiKTeXException'
This can typically be ignored.
Best,
Uwe Ligges
Kind regards
Christiaan
On Thu, 28 Dec 2023 at 15:55, Ivan Krylov wrote:
Hi Christiaan,
В Thu, 28 Dec 2023 14:57:55 +0200
Christiaan Pieterse пишет:
Still, I couldn't figure out why I ran into this problem, so I
created a test file called "Test Example.R" (available at the same
GitHub repository:
https://github.com/WoutersResearchGroup/R-IO-PS/tree/CRAN-prep).
I see you're always adding or updating files to the GitHub repo by
means of uploading. While that's certainly one way to use GitHub, it's
combines the least convenient aspects of two approaches to using GitHub.
With GitHub purely in the browser, GitHub is just a website where you
keep and edit code, running nothing else on the local computer. Code
can be run in Codespaces or using GitHub Actions. Microsoft will want
to be paid money to run code on their computers.
With GitHub as a Git remote, there is a local checkout [*] that's kept
in sync with GitHub by means of commits [**] and pushes [***], letting
you create meaningful, describable snapshots of changes in your code
spanning multiple files at the same time.
Right now, it probably feels like Dropbox but worse.
This file creates the function in the global environment (note that
this is the same function code as available in the package
"R/iopspackage2.0.R" file), and then runs this function with the same
example as in the package (If you want to try this yourself, just
load the data/ExampleTradeData.rda in before running the Test Example
file). This test file yields no errors when I run it and produces the
correct results. When I then proceed to build and check the package,
it yields the same example error as before. I do not understand why
or what could cause this issue.
The difference is in the ExampleTradeData variable, which "Test
Example.R" doesn't define.
With data(ExampleTradeData), the script works.
With ExampleTradeData <-
read.csv(system.file("extdata","ExampleTradeData.csv",package="iopspackage")),
the script fails exactly the same way as example(IOPS) does.
I'm not sure if I should send out another email to the developers to
see if someone else spots something I'm not seeing.
It may help to keep Cc: r-package-devel@r-project.org in the e-mails
for the search engines to index the potential solutions in the mailing
list archives.
--
Best regards,
Ivan
[*]
https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository
[**]
https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository
[***]
https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes
[[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
[R-pkg-devel] CRAN submission queue closes from Dec 22 to Jan 8
Dear package developers, reminder as announced on the CRAN web page for some months now: the CRAN submission queue closes and will be offline from Dec 22 to Jan 8 due to CRAN team vacations and maintainance work on the CRAN check farm. Best, Uwe Ligges __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Installation error on Windows during CRAN pretest
This was a temporary hicc up on the machine and we triggered new checks.
Best,
Uwe Ligges
On 15.12.2023 02:29, Wilke, Claus O wrote:
Hello,
I just tried to submit my package ggridges to CRAN and got an error during the
pretest on Windows. I have no idea what the error means, and my package tested
fine on win-builder, for both R release and R devel.
The specific error during install is:
* installing *source* package 'ggridges' ...
** using staged installation
Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'Europe/Berlin'
Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
Warning in as.POSIXlt.POSIXct(x, tz) :
unknown timezone 'America/New_York'
Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
Warning in as.POSIXlt.POSIXct(x, tz) :
unknown timezone 'America/New_York'
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
Error in if (file.size(codeFile) == file.size(loaderFile)) warning("package seems to
be using lazy loading already") else { :
missing value where TRUE/FALSE needed
Calls:
Execution halted
ERROR: lazy loading failed for package 'ggridges'
* removing 'd:/RCompile/CRANincoming/R-devel/lib/ggridges’
The output during check also states an error:
* using log directory 'd:/RCompile/CRANincoming/R-devel/ggridges.Rcheck'
* using R Under development (unstable) (2023-12-14 r85685 ucrt)
* using platform: x86_64-w64-mingw32
* R was compiled by
gcc.exe (GCC) 12.3.0
GNU Fortran (GCC) 12.3.0
* running under: Windows Server 2022 x64 (build 20348)
* using session charset: UTF-8
* checking for file 'ggridges/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'ggridges' version '0.5.5'
* package encoding: UTF-8
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Claus O. Wilke '
Reading Rd files failed with
cannot open the connection
Checking DOIs failed with message:
cannot open the connection
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking serialization versions ... OK
* checking whether package 'ggridges' can be installed ... ERROR
Installation failed.
See 'd:/RCompile/CRANincoming/R-devel/ggridges.Rcheck/00install.out' for
details.
* DONE
Status: 1 ERROR, 1 NOTE
You can see the complete logs here:
https://win-builder.r-project.org/incoming_pretest/ggridges_0.5.5_20231214_220108/
My package source is here: https://github.com/wilkelab/ggridges
I’d appreciate any help in resolving this. I have no idea what to try other
than to just submit again and cross my fingers.
Thanks!
Claus
--
Claus Wilke
Blumberg Centennial Professor in Molecular Evolution
The University of Texas at Austin
2415 Speedway #C0930, Austin, Texas 78712
__
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] Getting 'Rscript: Bad address' error when CRAN build my package on windows platforms
On 07.12.2023 19:29, Serge wrote: Hello, I'm the maintener of the rtkore package and I'm experimenting an error during the installation on the |r-devel-windows-x86_64| and the |r-release-windows-x86_64| platform. When trying to compile I get |g++ -std=gnu++11 -I"D:/RCompile/recent/R-4.3.2/include" -DNDEBUG -I../inst/projects/ -I../inst/include/ -DIS_RTKPP_LIB -DSTKUSELAPACK -I'D:/RCompile/CRANpkg/lib/4.3/Rcpp/include' -I"d:/rtools43/x86_64-w64-mingw32.static.posix/include" -fopenmp -O2 -Wall -mfpmath=sse -msse2 -mstackrealign -c fastRand.cpp -o fastRand.o /bin/sh: line 1: /x86_64-w64-mingw32.static.posix/bin/g++: Bad address | A search indicate that the problem is from the "D:" (not sure it is the correct answer) Well, the missing d: or /d/ in the last line of your cited output. Which package is this? Then I could take a look into the sources. Best, Uwe Ligges In all case, I cannot modify these path as there given by the CRAN mechanism of compilation. Can you give me some hints about the problem and how to solve it ? Thanks [[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
Re: [R-pkg-devel] macos x86 oldrel backups?
Have you sent a note to the Mac maintainer already? Best, Uwe Ligges On 04.12.2023 21:52, Jonathan Keane wrote: Thank you to the CRAN maintainers for maintenance and keeping the all of the CRAN infrastructure running. I'm seeing a long delay in builds on CRAN for r-oldrel-macos-x86_64. I'm currently interested in Arrow [1], but I'm seeing many other packages with similar missing r-oldrel-macos-x86_64 builds (possibly all, I sampled a few packages from [2], but didn't do an exhaustive search) for an extended period. It appears that this started between 2023-10-21 and 2023-10-22. It looks like AMR [3] has a successful build but xlcutter does not [4] and all the packages I've checked after 2023-10-22 don't have an updated build for r-oldrel-macos-x86_64 Sorry if this is scheduled maintenance, I tried to find an announcement here and on r-project.org but haven't yet found anything indicating this. [1] - https://cran.r-project.org/web/checks/check_results_arrow.html [2] - https://cran.r-project.org/web/packages/available_packages_by_date.html [3] - https://cran.r-project.org/web/packages/AMR/index.html [4] - https://cran.r-project.org/web/packages/xlcutter/index.html -Jon __ 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] Update timing of machines on CRAN?
Thanks for your offer to providing us with capable multicore servers and support staff for continuing support of recent Fedora systems. Best, Uwe Ligges On 04.12.2023 18:09, andrew--- via R-package-devel wrote: I do think that its a reasonable ask that the test machines be running operating systems within their vendor support periods. -Andrew Robbins From: R-package-devel on behalf of Josiah Parry Sent: Monday, December 4, 2023 11:34 AM To: Tomas Kalibera Cc: R Package Development Subject: Re: [R-pkg-devel] Update timing of machines on CRAN? Unfortunately, it is often important for us to pay attention to what machines our code is being tested on. I think the point is more or less that we often find ourselves trying to make super small adjustments for machines and builds that are used by a number of users in the single digits. The vast majority of R programmers are not on these arcane machines. We should strive to support the vast majority of users who use *fairly* standard distributions such as Mac, Windows, Ubuntu, Debian, and maybe even Centos. Getting a note for a release which has reach EOL can be confusing and tough to know how to handle. On Mon, Dec 4, 2023 at 10:17 AM Tomas Kalibera wrote: On 12/4/23 15:44, SHIMA Tatsuya wrote: Thanks for your answer. Unlike Windows Server, which has a long support period, Fedora's support period is usually about one year, so it is surprising that the old Fedora continues to be used. And, unlike Windows, Linux uses the distribution standard packages for builds, which causes problems like the current Fedora machine that continues to use the old Rust. The configuration currently at different CRAN machines is just a sample of what your users might have, just an example of a setting packages should be able to deal with. Some users might also still have FC36, some might have another Linux distribution (possibly still supported), which has older software than that. I wouldn't recommend spending time tracking which version of which software CRAN systems currently happen to have, but rather making sure packages can deal with different versions (possibly with some in a restricted way, possibly making some hard requirements when necessary). Best Tomas Hope to see an update soon. Thanks to the staff for maintaining the infrastructure. Best, Tatsuya On 2023/12/01 23:43, Uwe Ligges wrote: On 01.12.2023 13:28, SHIMA Tatsuya wrote: Hi, I maintain the prqlr package that uses rustc for compiling, so I regularly check the version of Rust on CRAN. And I have noticed that the Rust version of Fedora has been stagnant for the past few months and was wondering why, but upon investigation I realized that this is because Fedora on CRAN is currently Fedora 36 (out of support in May). <https://cran.r-project.org/web/checks/check_flavors.html> It was quite a surprise to me that out of support Fedora is being used, but what is the normal cycle for machines on CRAN to be updated? And do we have any way of knowing that schedule? It depends on the maintainer who cares about these machine, the institution where it is hosted, the availability of technical staff, and the technical pressure. I could not even say when the machines I maintain will be updated. On one version of the retired winbuilder severs we kept the same OS version for almost 10 years. Best, Uwe Ligges Best, Tatsuya __ 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 [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel [[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
Re: [R-pkg-devel] I'm trying to include phyloseq as a CRAN package dependency and for the life of me I can't figure it out
On 03.12.2023 21:19, Sharon Bewick wrote: I had this package included in a previous upload and it didn’t cause errors. However, now it is getting flagged as an error. I’ve included biocViews: phyloseq in the DESCRIPTION file, but that did not help. Unfortunately, I cannot make phyloseq a weak dependency. It can be installed through Bioconductor but not CRAN. Any advice, or examples would be appreciated. I have tried most of the ‘solutions’ I have found online without success. Can you tell us which package you are talking about? Otherwise we cannot say why you see the error. Best, Uwe Ligges Thanks! Sharon __ 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] Example files for functions reading binary files
On 03.12.2023 16:12, Josiah Parry wrote: Rafael, I believe the issue is that packages cannot include binary *executables.* If you have a binary file (such as a parquet file) in inst/extdata, I do not think that would be a problem. It would be a good idea to ensure that that file is small, though. I think downloading a file is a big no no to be ran on CRAN machines. I would personally advise against downloading anything. Same from here: meant are files containing executable code such as shared or statically linked libraries, executables etc. Binary data files are permitted. Best, Uwe Ligges On Sun, Dec 3, 2023 at 9:54 AM Rafael Ayala Hernandez < rafael.ayalahernan...@oist.jp> wrote: ello, I have added some functions to read binary files in my asteRisk package. The binary files that are read contain just arrays of coefficients and metadata about these. I would like to provide a small file of these to be used in the examples of the man page for the functions that read them. However, section 1.1 of "Writing R Extensions” states that no binary files are accepted in submissions to CRAN (https://cran.r-project.org/doc/manuals/R-exts.html) I was wondering if it would be acceptable to download the example file to a temporary file in the example themselves (and in fact, also in unit tests), and then read it from there? I could not find any statement against this in “Writing R Extensions”, but I would like to confirm that this is OK to do before submitting an updated version of the package to CRAN. Thanks a lot in advance Best wishes, Rafa [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel [[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
Re: [R-pkg-devel] Update timing of machines on CRAN?
On 01.12.2023 13:28, SHIMA Tatsuya wrote: Hi, I maintain the prqlr package that uses rustc for compiling, so I regularly check the version of Rust on CRAN. And I have noticed that the Rust version of Fedora has been stagnant for the past few months and was wondering why, but upon investigation I realized that this is because Fedora on CRAN is currently Fedora 36 (out of support in May). <https://cran.r-project.org/web/checks/check_flavors.html> It was quite a surprise to me that out of support Fedora is being used, but what is the normal cycle for machines on CRAN to be updated? And do we have any way of knowing that schedule? It depends on the maintainer who cares about these machine, the institution where it is hosted, the availability of technical staff, and the technical pressure. I could not even say when the machines I maintain will be updated. On one version of the retired winbuilder severs we kept the same OS version for almost 10 years. Best, Uwe Ligges Best, Tatsuya __ 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] URL woes at CRAN: Anaconda edition
On 30.11.2023 18:28, Aron Atkins wrote: On Thu, Nov 30, 2023 at 11:49 AM Dirk Eddelbuettel wrote: And *of course* the same URL resolves fine for me in the browser without any apparent redirect. Bit of a web newb here but is there anything I can do short of deleteing the badge? The badge you're referencing is hosted by a cloudflare CDN, which uses "magic" to return error responses to non-humans. You can see this behavior by running curl against the URL: curl -I https://anaconda.org/conda-forge/r-tiledb HTTP/2 400 server: cloudflare ... I have seen this behavior for other resources, but generally have experienced 403 responses. This urlchecker issue discusses what I had seen: https://github.com/r-lib/urlchecker/issues/26 I do not have guidance other than to either remove the URL or add a note stating that the 400 errors are only presented to robots. Perhaps CRAN occasionally adjusts its User-Agent to avoid some of these challenges? Not sure. Aron This (status 400) underlies manual inspection and we let this pass. Best, Uwe Ligges __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Coordination Needed: Update in ast2ast affecting paropt
On 29.11.2023 11:23, Konrad via R-package-devel wrote: Dear all, I have two packages on CRAN (ast2ast and paropt). Notably, paropt depends on ast2ast. Currently, I'm working on a major update of ast2ast which changes the API at specific points that are used by paropt. Thus, the update will break paropt. I am reaching out to seek your suggestions on how Ican smoothly navigate this transition with minimal disruption. If you cannot prepare paropt in a way that it works with both versions of ast2ast, you can at least prepare a new version that work with the new ast2ast and explain upon submission of axt2axt that paropt is well prepared for submissions once ast2ast got released. Best, Uwe Ligges Thanks a lot in advance. Best Konrad [[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
Re: [R-pkg-devel] Trouble with greek letter in figure title in R-devel
Not sure if it is yet part of the --as-cran checks.
But you can set the env var
_R_CHECK_MBCS_CONVERSION_FAILURE_=true
Best,
Uwe
On 14.11.2023 17:29, Ulrike Grömping wrote:
Thank you for spotting this, I should have found it myself :-(
I suppose I don't get this error even from latest R-devel because of the
settings of my Windows system?
Best, Ulrike
Am 14.11.2023 um 17:16 schrieb Uwe Ligges:
On 14.11.2023 15:45, Ulrike Groemping wrote:
Dear package developers,
I am struggling with an error on R devel (all flavors) that I cannot
reproduce with a freshly installed R-devel on my machine: Function
halfnormal in package DoE.base places the greek letter alpha in the
title of a figure. I changed the code to using plotmath about a month
ago (on CRAN request), and everything seemed fine then. Now, however,
R-devel produces an error message
(https://www.r-project.org/nosvn/R.check/r-devel-windows-x86_64/DoE.base-00check.html):
Error in title(...) :
conversion failure on 'Plot for rnorm.12., method = Lenth, α =
0.05' in 'mbcsToSbcs': for α (U+03B1)
Yes, and your code contains
titel <- bquote(paste("Plot for ", paste(xnam), ", method = ",
.(method),
", \U03B1 = ", .(alpha), sep=""))
So please change this to plotmath as in the instance further above in
your code where you already wrote
titel <- as.expression(bquote("Plot for "*.(xnam)*", "*alpha ==
.(alpha)))
Best,
Uwe Ligges
Calls: halfnormal ... -> plot -> plot.default ->
localTitle -> title
Execution halted
CRAN threaten to archive the package because of that error - so I
would really appreciate help on finding out what I should do (apart
from nasty things like writing alpha instead of using the greek letter).
The code in function halfnormal that creates the title in question
looks as follows:
## added August 1 5 2014, modified Oct 17 2023
if (is.null(titel)){
titel <- as.expression(bquote("Plot for "*.(xnam)*", "*alpha ==
.(alpha)))
dots$main <- titel
}
The list dots is later used in "do.call(plotfun, dots)".
Any recommendations?
Thanks and regards,
Ulrike
__
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] Trouble with greek letter in figure title in R-devel
On 14.11.2023 15:45, Ulrike Groemping wrote:
Dear package developers,
I am struggling with an error on R devel (all flavors) that I cannot
reproduce with a freshly installed R-devel on my machine: Function
halfnormal in package DoE.base places the greek letter alpha in the
title of a figure. I changed the code to using plotmath about a month
ago (on CRAN request), and everything seemed fine then. Now, however,
R-devel produces an error message
(https://www.r-project.org/nosvn/R.check/r-devel-windows-x86_64/DoE.base-00check.html):
Error in title(...) :
conversion failure on 'Plot for rnorm.12., method = Lenth, α = 0.05'
in 'mbcsToSbcs': for α (U+03B1)
Yes, and your code contains
titel <- bquote(paste("Plot for ", paste(xnam), ", method = ",
.(method),
", \U03B1 = ", .(alpha), sep=""))
So please change this to plotmath as in the instance further above in
your code where you already wrote
titel <- as.expression(bquote("Plot for "*.(xnam)*", "*alpha ==
.(alpha)))
Best,
Uwe Ligges
Calls: halfnormal ... -> plot -> plot.default -> localTitle
-> title
Execution halted
CRAN threaten to archive the package because of that error - so I would
really appreciate help on finding out what I should do (apart from nasty
things like writing alpha instead of using the greek letter).
The code in function halfnormal that creates the title in question looks
as follows:
## added August 1 5 2014, modified Oct 17 2023
if (is.null(titel)){
titel <- as.expression(bquote("Plot for "*.(xnam)*", "*alpha ==
.(alpha)))
dots$main <- titel
}
The list dots is later used in "do.call(plotfun, dots)".
Any recommendations?
Thanks and regards,
Ulrike
__
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] The problem with resubmitting the package to the Cran
On 08.11.2023 17:54, Karolina Marek wrote: Hello, I have the following case. I would like to resubmit a package to the Cran - per ARMA, which was archived on 2022-05-25, as it required the archived package 'matlab'. The new version of the 'matlab' was resubmitted to the Cran on 2022-06-01. So we would like that our package will also return to the Cran. I didn't change anything significant in the code inside. However, when I try to submit the package, I receive the following NOTES: checking CRAN incoming feasibility ... NOTE * checking for non-standard things in the check directory ... NOTE Found the following files/directories: ‘PARMA21del1_ident' Apparently you create this file during the checks. So examples or vignette code executed by users may write it into the user filespace. You must not write their by default nor in examples etc. Let the user choose the filename and otherwise, e.g., in examples, use tempdir() as a location for writing files. Best, Uwe Ligges I don't know really what this note mean and can I put the package anyway to Cran? Best regards, Karolina [[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
Re: [R-pkg-devel] Matrix and Mac OS
On 01.11.2023 03:51, Mikael Jagan wrote: Thanks. It seems that we were mistaken in our feeling (IIRC) that it would be "OK" to implicitly require '--no-manual' on versions of R from 3.5.0 to 4.2.1, not changing our Depends. We will fix this in Matrix 1.6-2, probably by conditionalizing or otherwise replacing the amsmath commands and probably _not_ by changing to depend on R >= 4.2.2. Martin may have more to say in "the morning". Note that dependin on R >= 4.2.2 does not work. We need dependencies of the form R >= x.y.0. This is also part of the checks. Reason is that we have only one binary repository for one R-x.y.? series. On WIndows, where we check with R-4.2.3, a binary would be created and hence R-4.2.[0-1] would not see any valid Matrix binaries. So please either make this work on R >= 4.2.0 or require R >= 4.3.0. If the latter, ideally with an interim version that works for R >= 4.2.0, so that we valid binaries with correct dependency declarations again. Best, Uwe In the mean time (i.e., while we are stuck with Matrix 1.6-1.1), it may help to update to R 4.2.3 on r-oldrel-macos-* and/or to have EdSurvey revert its strict version requirement, unless there are clear examples justifying one. Mikael On 2023-10-31 8:17 pm, Simon Urbanek wrote: Mikael, in that case I think your requirements are wrong - Matrix says R >= 3.5.0 which is apparently incorrect - from what you say it should be 4.2.2?. I can certainly update to 4.2.3 if necessary. Cheers, Simon On 1/11/2023, at 9:19 AM, Mikael Jagan wrote: Thanks. We did see those ERRORs, stemming from use (since Matrix 1.6-0) of amsmath commands in Rd files. These have been supported since R 4.2.2, but r-oldrel-macos-* (unlike r-oldrel-windows-*) continues to run R 4.2.0. My expectation was that those machines would begin running R >= 4.2.2 well before the R 4.4.0 release, but apparently that was wrong. I am hesitant to complicate our Rd files with conditions on R versions only to support PDF output for R < 4.2.2, but maybe we can consider it for the Matrix 1.6-2 release if it is really a barrier for others ... Mikael On 2023-10-31 3:33 pm, Simon Urbanek wrote: Mikael, current Matrix fails checks on R-oldrel so that's why only the last working version is installed: https://cran.r-project.org/web/checks/check_results_Matrix.html Cheers, Simon On 1/11/2023, at 4:05 AM, Mikael Jagan wrote: I am guessing that they mean EdSurvey: https://cran.r-project.org/web/checks/check_results_EdSurvey.html Probably Matrix 1.6-1.1 is not installed on r-oldrel-macos-arm64, even though it can be, because it was not released until R 4.3-z. AFAIK, methods for 'qr' have not been touched since Matrix 1.6-0, and even those changes should have been backwards compatible, modulo handling of dimnames (class sparseQR gained a Dimnames slot in 1.6-0). So I don't see a clear reason for requiring 1.6-1.1. Requiring 1.6-0 might make sense, if somehow EdSurvey depends on how class sparseQR preserves dimnames. But IIRC our rev. dep. checks at that time did not reveal problems with EdSurvey. Mikael On 2023-10-31 7:00 am, r-package-devel-requ...@r-project.org wrote: Paul, can you give us a bit more detail? Which package, which build and where you got the errors? Older builds may not have the latest Matrix. Cheers, Simon On 31/10/2023, at 11:26 AM, Bailey, Paul via R-package-devel wrote: Hi, I'm the maintainer for a few packages, one of which is currently failing CRAN checks on Mac OS because Matrix is not available in my required version (the latest). I had to fix a few things due to changes in the latest Matrix package because of how qr works and I thought, given the apparent API change, I should then require the latest version. My error is, "Package required and available but unsuitable version: 'Matrix'" When I look at the NEWS in Matrix there is no mention of Mac OS issues, what the latest stable version of Matrix is, nor when a fix is expected. What version do MacOS version test Matrix with by default? Where is this documented? I assumes it always tested with the latest version on CRAN, so I'm a bit surprised. Or will this be resolved soon and I shouldn't bother CRAN maintainers with a new version of my package? Best, Paul [[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
Re: [R-pkg-devel] Problem with "additional repository".
It was 0.0-20 that had another issue now explained privately. 0.0-21 passes cleanly. Best, Uwe On 17.10.2023 20:45, Ivan Krylov wrote: On Mon, 16 Oct 2023 17:08:28 +0200 Uwe Ligges wrote: I do not know which package this refers to, so cannot easily look. This seems to be about the eglhmm package. It seems to pass --as-cran checks on my machine, but I know it's not the full set of checks performed for new packages. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CMD check: Examples vs DEPENDS pkg
On 17.10.2023 21:34, Leonard Mada via R-package-devel wrote: Dear List members, Package Rpdf depends on package rgl. Multiple examples will call internally the rgl package to visualize the pdb molecule. When performing the CMD check: 1) Is the rgl package loaded each time anew for any of those examples? 2) If this is the case: Is it possible to load it only once per CMD check? Typically it is loaded once for the examples, once for each test file and once for each vignette that uses it. Best, Uwe Ligges Sincerely, Leonard __ 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] Problem with "additional repository".
Certainly there was more in the output that caused rejection as the
stuff you describe below seems to be fine.
I do not know which package this refers to, so cannot easily look.
Best,
Uwe
On 16.10.2023 11:25, Duncan Murdoch wrote:
Whoops, I just read the next line. Sorry!
On 15/10/2023 9:34 p.m., Rolf Turner wrote:
I have submitted a new package to CRAN, and this package has been
knocked back on the basis of a NOTE:
* checking package dependencies ... NOTE
Package suggested but not available for checking: 'ionChannelData'
This suggested package consists of data sets, the size of which is too
large to satisfy CRAN's constraints. I put this package in a repository
on github, from which it can be accessed by users.
My DESCRIPTION file contains the line:
Additional_repositories: https://rolfturner.r-universe.dev
The given URL seems to work, in that users can indeed load the
ionChannelData package via the command
install.packages("ionChannelData",repos="https://rolfturner.r-universe.dev;)
I was under the impression that this was all that I needed to do. The
CRAN checking process acknowledges the existence of the repository in
question:
Suggests or Enhances not in mainstream repositories:
ionChannelData
Availability using Additional_repositories specification:
ionChannelData yes https://rolfturner.r-universe.dev
>
So CRAN knows about this repository. Why can it not make use of it?
What can/should I do to resolve this problem?
I guess I could simply *not* Suggest ionChannelData. But what then, is
the point of the option of including an Additional_repositories field in
the DESCRIPTION file?
cheers,
Rolf Turner
__
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] Question regarding CRAN submission with notes
This is under discussion with the CRAN team now. Best, Uwe Ligges On 11.10.2023 09:06, Tony Wilkes wrote: Dear all, I'm trying to publish an R package to CRAN. Their checks come back with 2 NOTES. The first one is saying that the package is a new submission, and the second one is that there is a subdirectory with a package inside my package. Both notes are correct. I have explained in my submission comments that this is indeed a new submission. I also gave the following explanation for the second note in my submission comments: "There is 1 NOTE given by the R CMD check results. This is due to the fact that I have placed fake libraries with fake packages inside the "inst/tinytest/" folder. This was necessary to test the various import-system related functions in my package. As stated, these are fake packages, and only contain trivial functions of no consequence. These fake libraries with fake packages ONLY exist because it is necessary for proper and extensive unit testing, that is all." They asked me to fix these notes a few days ago. I replied (politely) repeating my comments a few days ago. I have not heard back from CRAN since. I am assuming that I am missing something, but CRAN won't explain what exactly I am missing. Here are the NOTES: Windows: <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwin-builder.r-project.org%2Fincoming_pretest%2Ftinycodet_0.1.0.4_20231009_210227%2FWindows%2F00check.log=05%7C01%7C%7Ce3fe951ba4c54110abbb08dbc8fb77c2%7C84df9e7fe9f640afb435%7C1%7C0%7C638324754614049791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Xh6fZd6iQjW6AOFtCAwwzhNO%2B5vyCh%2Fy5%2FEi25z7D%2Fg%3D=0<https://win-builder.r-project.org/incoming_pretest/tinycodet_0.1.0.4_20231009_210227/Windows/00check.log>> Status: 1 NOTE Debian: <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwin-builder.r-project.org%2Fincoming_pretest%2Ftinycodet_0.1.0.4_20231009_210227%2FDebian%2F00check.log=05%7C01%7C%7Ce3fe951ba4c54110abbb08dbc8fb77c2%7C84df9e7fe9f640afb435%7C1%7C0%7C638324754614049791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=0jOFqYf9Ar%2FBp1YVSZjfRHRdChzGPi5lSSuyLT2HAoM%3D=0<https://win-builder.r-project.org/incoming_pretest/tinycodet_0.1.0.4_20231009_210227/Debian/00check.log>> Status: 2 NOTEs More details are given in the directory: <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwin-builder.r-project.org%2Fincoming_pretest%2Ftinycodet_0.1.0.4_20231009_210227%2F=05%7C01%7C%7Ce3fe951ba4c54110abbb08dbc8fb77c2%7C84df9e7fe9f640afb435%7C1%7C0%7C638324754614049791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=73zTGLwQVRlTMnk20rbgTBOn5dCdu16y%2BmhlLS8GIpg%3D=0<https://win-builder.r-project.org/incoming_pretest/tinycodet_0.1.0.4_20231009_210227/>> Could anyone tell me what exactly I'm doing wrong? Thank you in advance. Kind regards, Tony [[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
Re: [R-pkg-devel] Link to MKL instead of RBLAS on CRAN
On 27.09.2023 14:11, Sameh Abdulah wrote: Hi, Is it possible to link with MKL instead of RBLAS when submitting my package to CRAN? Do CRAN support other BLAS libraries? Not quite sure what you aim at. You submit a source package. Make sure it can be linked with any BLAS. CRAN checks your package (after acceptance) with R versions linked against OpenBLAS, MKL, ATLAS etc. Binaries are always linked against Rblas for maximal compatibility. Best, Uwe Ligges Best, --Sameh __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] vapply and More Complex FUN.VALUE
On 27.09.2023 09:35, Ivan Krylov wrote: On Tue, 26 Sep 2023 20:00:03 + Dario Strbenac wrote: Is it possible to somehow specify more complex return types, such as a data.frame with specific columns? Probably not with vapply(). It only looks at the equivalent of typeof(), verifies the length() (which for data.frames is the number of columns) and then combines the objects along the axis that you're not interested in (building a list-matrix). I've been using the do.call(rbind, lapply(...)) idiom, relying on rbind.data.frame to check its arguments. It could probably be made more efficient, but it does the job. Or perhaps you simply look for defining a new class (I'd use S3) where the output is a specific data frame (with some prefedined columns) to which you assign a class attribute? Best, Uwe Ligges __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Checking the number of cores used
On 18.09.2023 16:10, Shu Fai Cheung wrote: Hi All, I know we should not use more than 2 cores in tests, vignettes, etc. I encountered and solved this issue before. However, I still committed this mistake in a new package and would like find out where the cause is. I have a package that already has parallel processing disabled by default and I did not enable parallel processing in the examples and tests (except for one test, which is always skipped by skip()). However, I was told that somewhere in the package more than 2 cores are used. I checked several times and even added a temporary 'stop()` to "trap" parallel processing but still could not find where the source of the problem is. I checked the timing in the log in R CMD check results from winbuilder but everything seems OK. The user time and elapsed time are similar for all the examples. Is there any quick way to check where things go wrong regarding the number of cores? It is not easy to find the source of the problems when there are many examples and tests. If it is OK on winbuilder but not on Linux, then likely something makes use of multithreading. Best, Uwe Ligges Regards, Shu Fai __ 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] Spelling of PDB in Package Description
On 14.09.2023 23:35, Leonard Mada wrote:
Dear Uwe,
I found out what is going on. There is an example:
## Write the pdb object in file "Rpdb.pdb" into the current directory
write.pdb(pdb, file = "Rpdb.pdb")
In examples, you should write to tempdir(), if at all.
Best,
Uwe Ligges
The example was present in the previous version as well. So I did not
thought about it. I do not know how to handle this: although the example
should probably remain.
Sincerely,
Leonard
On 9/15/2023 12:27 AM, Uwe Ligges wrote:
The spellng is fine and not a problem.
For
* checking for non-standard things in the check directory ... NOTE
Found the following files/directories:
‘Rpdb.pdb’
You need to move this to ./inst or a subdirectory or, if data,
consider ./extdata See Writing R Extensions.
Best,
Uwe Ligges
On 14.09.2023 22:06, Avraham Adler wrote:
Regarding PDB, in Rd format it’s best to wrap that in an \acronym{}
tag. See section 2.3 of
https://cran.r-project.org/doc/manuals/R-exts.html#Marking-text
Avi
Sent from my iPhone
On Sep 14, 2023, at 3:40 PM, Leonard Mada via R-package-devel
wrote:
Dear List Members,
After resubmitting the updated version of the Rpdb package (2.3.1),
the following Notes were generated:
1.) Spelling PDB
https://win-builder.r-project.org/incoming_pretest/Rpdb_2.3.1_20230914_173458/Windows/00check.log
https://win-builder.r-project.org/incoming_pretest/Rpdb_2.3.1_20230914_173458/Debian/00check.log
The PDB stands for Protein Data Bank:
http://www.wwpdb.org/documentation/file-format-content/format33/v3.3.html
It should be the correct spelling (and was the same in the previous
versions of the package).
2.) Small Sample PDB Files
* checking for non-standard things in the check directory ...
NOTE Found the following files/directories: ‘Rpdb.pdb’
There is a directory with 3 very small sample pdb-files. The
directory was also present in the previous version.
How should I proceed? Or did I miss something?
Sincerely,
Leonard
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[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
Re: [R-pkg-devel] Spelling of PDB in Package Description
The spellng is fine and not a problem.
For
* checking for non-standard things in the check directory ... NOTE
Found the following files/directories:
‘Rpdb.pdb’
You need to move this to ./inst or a subdirectory or, if data, consider
./extdata See Writing R Extensions.
Best,
Uwe Ligges
On 14.09.2023 22:06, Avraham Adler wrote:
Regarding PDB, in Rd format it’s best to wrap that in an \acronym{} tag. See
section 2.3 of https://cran.r-project.org/doc/manuals/R-exts.html#Marking-text
Avi
Sent from my iPhone
On Sep 14, 2023, at 3:40 PM, Leonard Mada via R-package-devel
wrote:
Dear List Members,
After resubmitting the updated version of the Rpdb package (2.3.1), the
following Notes were generated:
1.) Spelling PDB
https://win-builder.r-project.org/incoming_pretest/Rpdb_2.3.1_20230914_173458/Windows/00check.log
https://win-builder.r-project.org/incoming_pretest/Rpdb_2.3.1_20230914_173458/Debian/00check.log
The PDB stands for Protein Data Bank:
http://www.wwpdb.org/documentation/file-format-content/format33/v3.3.html
It should be the correct spelling (and was the same in the previous versions of
the package).
2.) Small Sample PDB Files
* checking for non-standard things in the check directory ...
NOTE Found the following files/directories: ‘Rpdb.pdb’
There is a directory with 3 very small sample pdb-files. The directory was also
present in the previous version.
How should I proceed? Or did I miss something?
Sincerely,
Leonard
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[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
Re: [R-pkg-devel] How to fix Archived Package Rpdb?
On 09.09.2023 20:15, Leonard Mada via R-package-devel wrote:
Thank you very much for this help.
1.) I am a little bit unsure about the LICENSE file - see below (in-text).
2.) There is a new error in the meantime:
- the check works on Windows, but fails everywhere else with:
Warning: Found the following significant warnings:
Warning: 'rgl.init' failed, running with 'rgl.useNULL = TRUE'.
On non Windows systems, You cannot use rgl if you do not have any X11
available.
Support for Unix alikes is optional, so in packages X11() should be used
conditionally after checking capabilities("X11").
Googling the web was not very informative either: it mentions something
about quartz device - but I am uncertain what to do.
>
On 9/8/2023 6:59 PM, Hadley Wickham wrote:
On Fri, Sep 8, 2023 at 6:02 AM Leonard Mada via R-package-devel
wrote:
Dear Members,
I would like to reanimate the archived package Rpdb:
https://cran.r-project.org/web/packages/Rpdb/index.html
[...]
2.b.) Description file
- I left the original author as the author (with the provided e-mail
address): should I delete this email?
It probably doesn't matter than much either way, but since the author
doesn't appear to respond to emails to that address, I personally
would lean towards deleting it.
Do *not* delete any authours/copyright holders.
- I have added myself as maintainer; [...]
- updated the licence to GPL v3: the original does not specify any
version number;
Is there anything else that needs to be done?
There are at least three 3 R CMD check failures you need to address:
* [...]
* You need to add LICENSE to .Rbuildignore, or and IMO better, delete
that file and use usethis::use_gpl3_license() to the license in
markdown form, and correctly ignored for CRAN submission
If I understand correctly:
- delete the "LICENSE" file and use usethis::use_gpl3_license(), which
adds the "LICENSE.md" file;
- should I also add some code to the DESCRIPTION file?
LICENSE: GPL-3
in the DESCRIPTION should be fine, and no license file unless you want
to add additional restrictions that are permitted by GPL-3 such as
attribution requirements.
No idea what usethis::use_gpl3_license() does.
Best,
Uwe Ligges
* Many examples use `\%in\%` instead of `%in%.
Hopefully, this is fixed now. But it was quit a hassle to find out which
files were affected. [I could have used gawk, but the error-reporting
could be improved as well!]
Sincerely,
Leonard
To make these sorts of problems easier to spot in the future I'd
suggest setting up a GitHub action to automatically run R CMD check
every time you push to GitHub. One easy way to do that is to run
usethis::use_github_action("check-standard").
Hadley
[[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
Re: [R-pkg-devel] URL syntax causes R CMD build failure - a fix
John can you point us to an example? Where is it in your package and what is the R CMD check output? Guess: Within an Rd file you have to escape the % characters otherwise they start a comment. Best, Uwe Ligges On 03.09.2023 00:30, Spencer Graves wrote: I've encountered similar issues. However, it has been long enough ago that I don't remember enough details to say more without trying to update my CRAN packages to see what messages I get and maybe researching my notes from previous problems of this nature. Spencer Graves On 9/2/23 4:23 PM, Greg Hunt wrote: The percent encoded characters appear to be valid in that URL, suggesting that rejecting them is an error. That kind of error could occur when the software processing them converts them back to a non-unicode character set. On Sun, 3 Sep 2023 at 4:34 am, J C Nash wrote: I'm posting this in case it helps some other developers getting build failure. Recently package nlsr that I maintain got a message that it failed to build on some platforms. The exact source of the problem is still to be illuminated, but seems to be in knitr::render and/or pandoc or an unfortunate interaction. An update to pandoc triggered a failure to process a vignette that had been happily processed for several years. The error messages are unhelpful, at least to me, Error at "nlsr-devdoc.knit.md" (line 5419, column 1): unexpected end of input Error: pandoc document conversion failed with error 64 Execution halted Unfortunately, adding "keep_md: TRUE" (you need upper case TRUE to save it when there is no error of this type), did not save the intermediate file in this case. However, searching for "pandoc error 64" presented one web page where the author used brute force search of his document by removing / replacing sections to find the line(s) that caused trouble. This is a little tedious, but effective. In my case, the offending line turned out to be a copied and pasted URL https://en.wikipedia.org/wiki/Levenberg%E2%80%93Marquardt_algorithm The coded characters can be replaced by a hyphen, to give, https://en.wikipedia.org/wiki/Levenberg-Marquardt_algorithm and this, when pasted in Mozilla Firefox at least, will go to the appropriate wikipedia page. I'd be interested in hearing from others who have had similar difficulties. I suspect this is relatively rare, and causing some sort of infelicity in the output of knitr::render that then trips up some versions of pandoc, that may, for instance, be now applying stricter rules to URL syntax. Best, John Nash __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel [[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 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] What to do when a package is archived from CRAN
To clarify: A packae must be single under a single license or a license and alternative licenes. You cannot have 2 licenses at the same time, hence ou have to relicense anyway. Of course, you have to check whether the licneses allow for it or seek confirmation from all copyright holders. If that (relicensing) is nt possible, you cannpt bundle such software components in a single package. Best, Uwe Ligges On 31.08.2023 17:04, Iñaki Ucar wrote: About licensing, On Sun, 27 Aug 2023 at 17:30, SHIMA Tatsuya wrote: Hi Ivan, thanks for taking the time to look at all the details of this. > You licensed the package as MIT. Are your dependencies compatible with MIT? All direct dependencies of your Rust code seem to be licensed under either MIT or Apache-2.0, which seems to be compatible. I am not a legal expert, but as you have seen all of prqlr's dependent crates are compatible with the MIT license, and I interpret this to mean that there is no problem distributing anything containing them under the MIT license. No, that's not what "compatibility" means. You cannot just take n pieces of software, bundle them, and release them under a license of your choice (unless their licenses enable you to do so via some re-licensing clause, like the Artistic-2.0 license does). That's not the case here. By licensing your package as MIT, you are violating the terms of the Apache-2.0 license, because I assume that you are not modifying those dependencies at all. So your work should be both MIT and Apache-2.0 (and others, should they exist, and provided they are compatible). Best, __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Re-building vignettes had CPU time 9.2 times elapsed time
Dear all, in today's R Core meeting both the CRAN team and R Core agree with Simon's suggestion below. Let me repeat the key points: - We will try to add some interface to R that allows for more unified control about the various ways of parallelisation. That should allow users to opt in for more than 2 cores and/or threads and/or processes. Details will follow as this is not simple. - As long as users do not have simple ways of controlling how demanding code is (e.g., different ways of parallelizationare used even in nested ways), CRAN will further on protect users and enforce that packages do not use more than 2 cores by default. Best, Uwe Ligges On 26.08.2023 02:05, Simon Urbanek wrote: On Aug 26, 2023, at 11:01 AM, Dirk Eddelbuettel wrote: On 25 August 2023 at 18:45, Duncan Murdoch wrote: | The real problem is that there are two stubborn groups opposing each | other: the data.table developers and the CRAN maintainers. The former | think users should by default dedicate their whole machine to | data.table. The latter think users should opt in to do that. No, it feels more like it is CRAN versus the rest of the world. In reality it's more people running R on their laptops vs the rest of the world. Although people with laptops are the vast majority, they also are the least impacted by the decision going either way. I think Jeff summed up the core reasoning pretty well. Harm is done by excessive use, not other other way around. That said, I think this thread is really missing the key point: there is no central mechanism that would govern the use of CPU resources. OMP_THREAD_LIMIT is just one of may ways and even that is vastly insufficient for reasons discussed (e.g, recursive use of processes). It is not CRAN's responsibility to figure out for each package what it needs to behave sanely - it has no way of knowing what type of parallelism is used, under which circumstances and how to control it. Only the package author knows that (hopefully), which is why it's on them. So instead of complaining here better use of time would be to look at what's being used in packages and come up with a unified approach to monitoring core usage and a mechanism by which the packages could self-govern to respect the desired limits. If there was one canonical place, it would be also easy for users to opt in/out as they desire - and I'd be happy to help if any components of it need to be in core R. Take but one example, and as I may have mentioned elsewhere, my day job consists in providing software so that (to take one recent example) bioinformatics specialist can slice huge amounts of genomics data. When that happens on a dedicated (expensive) hardware with dozens of cores, it would be wasteful to have an unconditional default of two threads. It would be the end of R among serious people, no more, no less. Can you imagine how the internet headlines would go: "R defaults to two threads". If you run on such a machine then you or your admin certainly know how to set the desired limits. From experience the problem is exactly the opposite - it's far more common for users to not know how to not overload such a machine. As for internet headlines, they will always be saying blatantly false things like "R is not for large data" even though we have been using it to analyze terabytes of data per minute ... Cheers, Simon And it is not just data.table as even in the long thread over in its repo we have people chiming in using OpenMP in their code (as data.table does but which needs a different setter than the data.table thread count). It is the CRAN servers which (rightly !!) want to impose constraints for when packages are tested. Nobody objects to that. But some of us wonder if settings these defaults for all R user, all the time, unconditional is really the right thing to do. Anyway, Uwe told me he will take it to an internal discussion, so let's hope sanity prevails. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] What to do when a package is archived from CRAN
Friends, CRAN wrote initially to some rust using maintainers: The CRAN policy on authorship/copyright is very clear: "(’All components’ includes any downloaded at installation or during use.) " Please explain how your package complies if you believe it does. Further, we ask that you use the 'cargo vendor' mechanism to avoid downloading during installation and limit the number of CPUs 'cargo build' can use during installation. Both points are covered in <https://cran.r-project.org/web/packages/using_rust.html>." Accepting a package that downloads crates from github happened automatically, but incorrectly (a false negative): All the correspondence we see claims that the submission had bundled the rust code, but the version that got archived after publication was 104KB and did not. So please simply follow the mails you got and fix the package folwing the "using_rust" documentation. In addition, it was mentined already to get the authorship straight. Best, Uwe Ligges On 27.08.2023 17:28, SHIMA Tatsuya wrote: Hi Tim, thank you for sharing this information. i didn't know this. If this is the cause, the problem seems to have been resolved in the latest serde <https://github.com/serde-rs/serde/pull/2590>, so it seems to be possible to deal with it. Best, Tatsuya On 2023/08/27 20:24, Tim Taylor wrote: Could you have been caught out with the precompiled binary that serde started distributing in a few of it’s versions (https://github.com/serde-rs/serde/issues/2538)? That could have been a reason if you pinned a version with it present but only CRAN could confirm if that was the reason. Tim On 26 Aug 2023, at 22:22, Ivan Krylov wrote: On Sat, 26 Aug 2023 11:46:44 +0900 SHIMA Tatsuya wrote: I noticed that my submitted package `prqlr` 0.5.0 was archived from CRAN on 2023-08-19. <https://CRAN.R-project.org/package=prqlr> I submitted prqlr 0.5.0 on 2023-08-13. I believe I have since only received word from CRAN that it passed the automated release process. Sarah gave a good guess (although there are CRAN packages containing C++ and Rust code with NOTEs about size of their libs, 18.2Mb is still a lot), though I do find it strange that you didn't receive anything from CRAN prior to having your package archived. I don't think I ever had problems with e-mails being delivered from CRAN to GMail, but we can't rule that out. You've obviously made an effort to follow the Rust policy, and I don't see any obvious problems with this part of the package, although I haven't tried it myself to verify the installation working offline from bundled source code. You've also made an effort to list all the authors of the code comprising your package in inst/AUTHORS, which is the right thing to do to avoid making the list of authors in DESCRIPTION long enough to be unreadable. You licensed the package as MIT. Are your dependencies compatible with MIT? All direct dependencies of your Rust code seem to be licensed under either MIT or Apache-2.0, which seems to be compatible. You named the copyright holder of your package as "prqlr authors", which may be a problem. (I think I saw it somewhere that for MIT license, CRAN prefers the copyright holder to be some kind of legal entity: either the legal name of a person, or a company, or something like that.) Could the Rust code or any of the dependencies accidentally write under the user's home directory or take over the terminal or something like that? We might need a response from CRAN after all. -- Best regards, Ivan __ 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 submissions no auto-processed message
Thanks.This was pending a manual inspection for newbies (packages). ALthough, we also have no mail with test results (I guess a CRAN server's mail issue when this hot checked), so I just triggered new checks. Best, Uwe Ligges On 28.08.2023 00:37, John Harrold wrote: Oh I'm sorry. It's the ruminate package. On Sun, Aug 27, 2023 at 2:22 PM Uwe Ligges <mailto:lig...@statistik.tu-dortmund.de>> wrote: On 27.08.2023 22:51, John Harrold wrote: > Howdy Folks, > > I submitted a package on Friday. I got the normal email where you have to > click on the link to confirm. Then I got an email saying that the package > was uploaded. Normally after that I get an email saying the package was > auto-processed. That generally doesn't take very long (typically less than > an hour). I wanted to know if there was something on the backend that was > causing a delay, or if there was something wrong and I needed to resubmit > it. Not that I know. If you told us which package this is about ... Best, Uwe Ligges > > Thank you, > John > :wq > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org <mailto:R-package-devel@r-project.org> mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel <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 submissions no auto-processed message
On 27.08.2023 22:51, John Harrold wrote: Howdy Folks, I submitted a package on Friday. I got the normal email where you have to click on the link to confirm. Then I got an email saying that the package was uploaded. Normally after that I get an email saying the package was auto-processed. That generally doesn't take very long (typically less than an hour). I wanted to know if there was something on the backend that was causing a delay, or if there was something wrong and I needed to resubmit it. Not that I know. If you told us which package this is about ... Best, Uwe Ligges Thank you, John :wq [[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
Re: [R-pkg-devel] Trouble with long-running tests on CRAN debian server
On 23.08.2023 16:00, Scott Ritchie wrote:
Hi Uwe,
I agree and have also been burnt myself by programs occupying the
maximum number of cores available.
My understanding is that in the absence of explicit parallelisation, use
of data.table in a package should not lead to this type of behaviour?
Yes, that would be my hope, too.
Best,
Uwe Ligges
Best,
Scott
On Wed, 23 Aug 2023 at 14:30, Uwe Ligges
<mailto:lig...@statistik.tu-dortmund.de>> wrote:
I (any many collegues here) have been caught several times by the
following example:
1. did something in parallel on a cluster, set up via
parallel::makeCluster().
2. e.g. allocated 20 cores and got them on one single machine
3. ran some code in parallel via parLapply()
Bang! 400 threads;
So I have started 20 parallel processes, each of which is using the
automatically set max. 20 threads as OMP_THREAD_LIMIT was also adjusted
by the cluster to 20 (rather than 1).
Hence, I really believe a default should always be small, not only in
examples and tests, but generally. And people who aim for more
should be
able to increase the defaults.
Do you believe a software that auto-occupies a 96 core machines with 96
threads by default is sensible?
Best,
Uwe Ligges
On 21.08.2023 21:59, Berry Boessenkool wrote:
>
> If you add that to each exported function, isn't that a lot of
code to read + maintain?
> Also, it seems like unnecessary computational overhead.
> From a software design point of view, it might be nicer to set
that in the examples + tests.
>
> Regards,
> Berry
>
>
> From: R-package-devel mailto:r-package-devel-boun...@r-project.org>> on behalf of Scott
Ritchie mailto:sritchi...@gmail.com>>
> Sent: Monday, August 21, 2023 19:23
> To: Dirk Eddelbuettel mailto:e...@debian.org>>
> Cc: r-package-devel@r-project.org
<mailto:r-package-devel@r-project.org>
mailto:r-package-devel@r-project.org>>
> Subject: Re: [R-pkg-devel] Trouble with long-running tests on
CRAN debian server
>
> Thanks Dirk and Ivan,
>
> I took a slightly different work-around of forcing the number of
threads to
> 1 when running functions of the test dataset in the package, by
adding the
> following to each user facing function:
>
> ```
> # Check if running on package test_data, and if so, force
data.table to
> be
> # single threaded so that we can avoid a NOTE on CRAN submission
> if (isTRUE(all.equal(x, ukbnmr::test_data))) {
> registered_threads <- getDTthreads()
> setDTthreads(1)
> on.exit({ setDTthreads(registered_threads) }) # re-register
so no
> unintended side effects for users
> }
> ```
> (i.e. here x is the input argument to the function)
>
> It took some trial and error to get to pass the CRAN tests; the
number of
> columns in the input data was also contributing to the problem.
>
> Best,
>
> Scott
>
>
> On Mon, 21 Aug 2023 at 14:38, Dirk Eddelbuettel mailto:e...@debian.org>> wrote:
>
>>
>> On 21 August 2023 at 16:05, Ivan Krylov wrote:
>> | Dirk is probably right that it's a good idea to have
OMP_THREAD_LIMIT=2
>> | set on the CRAN check machine. Either that, or place the
responsibility
>> | on data.table for setting the right number of threads by
default. But
>> | that's a policy question: should a CRAN package start no more
than two
>> | threads/child processes even if it doesn't know it's running in an
>> | environment where the CPU time / elapsed time limit is two?
>>
>> Methinks that given this language in the CRAN Repository Policy
>>
>> If running a package uses multiple threads/cores it must
never use more
>> than two simultaneously: the check farm is a shared resource
and will
>> typically be running many checks simultaneously.
>>
>> it would indeed be nice if this variable, and/or equivalent
ones, were set.
>>
>> As I mentioned before, I had long added a similar throttle (not for
>> data.table) in a package I look after (for work, even). So a similar
>> throttler with optionality is below. I'll add this to my `dang`
package
>> collecting various functions.
>>
>> A usage example follows. It does nothing by default, ensuring
'full power'
>> but reflects the minimum of two
Re: [R-pkg-devel] Re-building vignettes had CPU time 9.2 times elapsed time
* checking re-building of vignette outputs ... [577s/63s] NOTE Re-building vignettes had CPU time 9.2 times elapsed time --> Do not use more than 2 cores Best, Uwe Ligges On 24.08.2023 13:42, Fred Viole wrote: Hi, I am receiving a NOTE upon submission regarding the re-building of vignettes for CPU time for the Debian check. I am unable to find any documented instances or solutions to this issue. The vignettes currently build in 1m 54.3s locally and in 56s on the Win check. https://win-builder.r-project.org/incoming_pretest/NNS_10.1_20230824_132459/Debian/00check.log Thank you for your assistance, Fred [[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
Re: [R-pkg-devel] Trouble with long-running tests on CRAN debian server
On 23.08.2023 15:58, Jeff Newmiller wrote:
To whom are you addressing this question? The OpenMP developers who define the
missing-OMP_THREAD_LIMIT behaviour and-or supply default config files? The CRAN
server administrators who set the variable in their site-wide configuration
intentionally or unintentionally? Or the package authors expected to kludge in
settings to override those defaults for CRAN testing while not overriding them
in normal use?
Of course , the CRAN teams controls the env vars on the CRAN servers,
but not on a server a user might use. And a user is typically unaware
that a package uses multithreading.
R users are typically not developers with a lot of insight in computer
science. Most R users I know would not even know how to set an env var.
So why do you ecxpect your users to set an appropriate OMP_THREAD_LIMIT?
Particularly when they aim at parallelization, they have to set it to 1.
I advocate not only to limit the number of cores for CRAN but also (and
inparticular) the default! Something we cannot check easily.
An alternative would be to teach R to set OMP_THREAD_LIMIT=1 locally by
default and a mechanism to change that for users.
Best,
Uwe Ligges
I would vote for explicitly addressing this (rhetorical?) question to the CRAN
server administrators...
On August 23, 2023 6:31:01 AM PDT, Uwe Ligges
wrote:
I (any many collegues here) have been caught several times by the following
example:
1. did something in parallel on a cluster, set up via parallel::makeCluster().
2. e.g. allocated 20 cores and got them on one single machine
3. ran some code in parallel via parLapply()
Bang! 400 threads;
So I have started 20 parallel processes, each of which is using the
automatically set max. 20 threads as OMP_THREAD_LIMIT was also adjusted by the
cluster to 20 (rather than 1).
Hence, I really believe a default should always be small, not only in examples
and tests, but generally. And people who aim for more should be able to
increase the defaults.
Do you believe a software that auto-occupies a 96 core machines with 96 threads
by default is sensible?
Best,
Uwe Ligges
On 21.08.2023 21:59, Berry Boessenkool wrote:
If you add that to each exported function, isn't that a lot of code to read +
maintain?
Also, it seems like unnecessary computational overhead.
From a software design point of view, it might be nicer to set that in the
examples + tests.
Regards,
Berry
From: R-package-devel on behalf of Scott
Ritchie
Sent: Monday, August 21, 2023 19:23
To: Dirk Eddelbuettel
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Trouble with long-running tests on CRAN debian server
Thanks Dirk and Ivan,
I took a slightly different work-around of forcing the number of threads to
1 when running functions of the test dataset in the package, by adding the
following to each user facing function:
```
# Check if running on package test_data, and if so, force data.table to
be
# single threaded so that we can avoid a NOTE on CRAN submission
if (isTRUE(all.equal(x, ukbnmr::test_data))) {
registered_threads <- getDTthreads()
setDTthreads(1)
on.exit({ setDTthreads(registered_threads) }) # re-register so no
unintended side effects for users
}
```
(i.e. here x is the input argument to the function)
It took some trial and error to get to pass the CRAN tests; the number of
columns in the input data was also contributing to the problem.
Best,
Scott
On Mon, 21 Aug 2023 at 14:38, Dirk Eddelbuettel wrote:
On 21 August 2023 at 16:05, Ivan Krylov wrote:
| Dirk is probably right that it's a good idea to have OMP_THREAD_LIMIT=2
| set on the CRAN check machine. Either that, or place the responsibility
| on data.table for setting the right number of threads by default. But
| that's a policy question: should a CRAN package start no more than two
| threads/child processes even if it doesn't know it's running in an
| environment where the CPU time / elapsed time limit is two?
Methinks that given this language in the CRAN Repository Policy
If running a package uses multiple threads/cores it must never use more
than two simultaneously: the check farm is a shared resource and will
typically be running many checks simultaneously.
it would indeed be nice if this variable, and/or equivalent ones, were set.
As I mentioned before, I had long added a similar throttle (not for
data.table) in a package I look after (for work, even). So a similar
throttler with optionality is below. I'll add this to my `dang` package
collecting various functions.
A usage example follows. It does nothing by default, ensuring 'full power'
but reflects the minimum of two possible options, or an explicit count:
> dang::limitDataTableCores(verbose=TRUE)
Limiting data.table to '12'.
> Sys.setenv("OMP_THREAD_LIMIT"=3);
dang::limitDataTableCores(verbose=TRUE)
Limiti
Re: [R-pkg-devel] Trouble with long-running tests on CRAN debian server
I (any many collegues here) have been caught several times by the
following example:
1. did something in parallel on a cluster, set up via
parallel::makeCluster().
2. e.g. allocated 20 cores and got them on one single machine
3. ran some code in parallel via parLapply()
Bang! 400 threads;
So I have started 20 parallel processes, each of which is using the
automatically set max. 20 threads as OMP_THREAD_LIMIT was also adjusted
by the cluster to 20 (rather than 1).
Hence, I really believe a default should always be small, not only in
examples and tests, but generally. And people who aim for more should be
able to increase the defaults.
Do you believe a software that auto-occupies a 96 core machines with 96
threads by default is sensible?
Best,
Uwe Ligges
On 21.08.2023 21:59, Berry Boessenkool wrote:
If you add that to each exported function, isn't that a lot of code to read +
maintain?
Also, it seems like unnecessary computational overhead.
From a software design point of view, it might be nicer to set that in the
examples + tests.
Regards,
Berry
From: R-package-devel on behalf of Scott
Ritchie
Sent: Monday, August 21, 2023 19:23
To: Dirk Eddelbuettel
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Trouble with long-running tests on CRAN debian server
Thanks Dirk and Ivan,
I took a slightly different work-around of forcing the number of threads to
1 when running functions of the test dataset in the package, by adding the
following to each user facing function:
```
# Check if running on package test_data, and if so, force data.table to
be
# single threaded so that we can avoid a NOTE on CRAN submission
if (isTRUE(all.equal(x, ukbnmr::test_data))) {
registered_threads <- getDTthreads()
setDTthreads(1)
on.exit({ setDTthreads(registered_threads) }) # re-register so no
unintended side effects for users
}
```
(i.e. here x is the input argument to the function)
It took some trial and error to get to pass the CRAN tests; the number of
columns in the input data was also contributing to the problem.
Best,
Scott
On Mon, 21 Aug 2023 at 14:38, Dirk Eddelbuettel wrote:
On 21 August 2023 at 16:05, Ivan Krylov wrote:
| Dirk is probably right that it's a good idea to have OMP_THREAD_LIMIT=2
| set on the CRAN check machine. Either that, or place the responsibility
| on data.table for setting the right number of threads by default. But
| that's a policy question: should a CRAN package start no more than two
| threads/child processes even if it doesn't know it's running in an
| environment where the CPU time / elapsed time limit is two?
Methinks that given this language in the CRAN Repository Policy
If running a package uses multiple threads/cores it must never use more
than two simultaneously: the check farm is a shared resource and will
typically be running many checks simultaneously.
it would indeed be nice if this variable, and/or equivalent ones, were set.
As I mentioned before, I had long added a similar throttle (not for
data.table) in a package I look after (for work, even). So a similar
throttler with optionality is below. I'll add this to my `dang` package
collecting various functions.
A usage example follows. It does nothing by default, ensuring 'full power'
but reflects the minimum of two possible options, or an explicit count:
> dang::limitDataTableCores(verbose=TRUE)
Limiting data.table to '12'.
> Sys.setenv("OMP_THREAD_LIMIT"=3);
dang::limitDataTableCores(verbose=TRUE)
Limiting data.table to '3'.
> options(Ncpus=2); dang::limitDataTableCores(verbose=TRUE)
Limiting data.table to '2'.
> dang::limitDataTableCores(1, verbose=TRUE)
Limiting data.table to '1'.
>
That makes it, in my eyes, preferable to any unconditional 'always pick 1
thread'.
Dirk
##' Set threads for data.table respecting possible local settings
##'
##' This function set the number of threads \pkg{data.table} will use
##' while reflecting two possible machine-specific settings from the
##' environment variable \sQuote{OMP_THREAD_LIMIT} as well as the R
##' option \sQuote{Ncpus} (uses e.g. for parallel builds).
##' @title Set data.table threads respecting default settingss
##' @param ncores A numeric or character variable with the desired
##' count of threads to use
##' @param verbose A logical value with a default of \sQuote{FALSE} to
##' operate more verbosely
##' @return The return value of the \pkg{data.table} function
##' \code{setDTthreads} which is called as a side-effect.
##' @author Dirk Eddelbuettel
##' @export
limitDataTableCores <- function(ncores, verbose = FALSE) {
if (missing(ncores)) {
## start with a simple fallback: 'Ncpus' (if set) or else 2
ncores <- getOption("Ncpus", 2L)
## also consider OMP_THREAD_LIMIT (cf Writing R Extensions), gets
NA if envvar unset
ompcore
Re: [R-pkg-devel] status of "possibly invalid URL/403 error" NOTEs?
On 13.08.2023 22:57, Avraham Adler wrote:
I had a similar issue with a paper on JSTOR. Usually CRAN let it through.
However, I eventually switched from URL to DOI and now the user needs to find
the free source so to rid myself of the constant hassle. CRAN really doesn’t
like redirects. I guess you could wrap it in \code{} so as not to hyperlink.
Avi
Sent from my iPhone
On Aug 13, 2023, at 3:17 PM, Ben Bolker wrote:
I have a package whose documentation includes the reference
\doi{10.1137/18M1186411} which redirects here:
https://epubs.siam.org/doi/10.1137/18M1186411
Running R CMD check --as-cran on the package gives
Found the following (possibly) invalid URLs:
URL: https://epubs.siam.org/doi/10.1137/18M1186411
From: man/llig.Rd
Status: 403
Message: Forbidden
CRAN will snpect this manually and let is pass.
Best,
Uwe Ligges
I can access this perfectly well in the browser.
Is there any way to avoid this (other than, say, including the URL in a form that does
*not* provide a link so that R CMD check won't try to access it? (As Uwe Ligges says
[here](https://stat.ethz.ch/pipermail/r-package-devel/2020q1/005195.html) (for a more
obviously problematic case), "mention the URL in plain text but not link"
Here Hadley Wickham says that these NOTEs can be ignored
https://twitter.com/hadleywickham/status/1358170607314235392
but "Hadley said it on twitter" is not an ideal source. The CRAN repository policy says
that packages must pass checks without "significant" notes, but it's always hard to know
what's significant and what's not ...
There's a thread here:
https://stat.ethz.ch/pipermail/r-package-devel/2020q1/005171.html
Tangentially: is there a more convenient way to search the r-package-devel archives
than googling (e.g.) "site:https://stat.ethz.ch/pipermail/r-package-devel 403"
?
__
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] Examples are too long in computation for CRAN
On 13.08.2023 08:14, Ivan Krylov wrote: В Sat, 12 Aug 2023 22:49:01 -0700 Michael Topper пишет: It appears that some of my examples/tests are taking too long to run for CRAN's standards. I don't think they are running too long; I think they are too parallel. The elapsed time is below 1s, but the "user" time (CPU time spent in the process) is 7 to 13 times that. This suggests that your code resulted in starting more threads than CRAN allows (up to 2 if you have to test parallellism). Are you using OpenMP? data.table? makeCluster()? It's simplest to always to default to a parallelism factor of 2 in examples an tests, because determining the right number is a hard problem. (What if the computer is busy doing something else? What if the BLAS is already parallel enough?) Moreover, is there any insight as to why this would happen on the third update of the package rather than on the first or second? The rule has always depended on the particular system running the checks (five seconds on my 12-year-old ThinkPad or on my ultraportative with an Intel Atom that had snails in its ancestry?). Maybe some dependency of your package has updated and started creating threads where it previously didn't. Good points, not only for examples and tests, but also for defaults. On shared resources (such as clusters) users may not expect the parallelization you use and then overallocate the resources. Example: 20 cores available to the user who runs makeCluster() for paallelization, but the underlying code does multihreading on 20 cores. Then we end up in 20*20 threads on the machine slowing down the machine and processes of other uers. Hence, defaults should also not be more than 2. Simply allow the user to ask for more. Best, Uwe Ligges __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] gdb availability on r-devel-linux-x86_64-fedora-gcc
On 12.08.2023 23:19, Dirk Eddelbuettel wrote:
On 12 August 2023 at 18:12, Uwe Ligges wrote:
| On 12.08.2023 15:10, Jamie Lentin wrote:
| > The system call in question is done by the TMB package[2], and not ours
| > to tinker with:
| >
| > cmd <- paste("R --vanilla < ",file," -d gdb --debugger-args=\"-x",
| > gdbscript,"\"")
| > txt <- system(cmd,intern=TRUE,ignore.stdout=FALSE,ignore.stderr=TRUE)
| >
| > My only vaguely reasonable guess is that gdb isn't available on the host
| > in question (certainly R will be!). How likely is this? Is it worth
| > trying to resubmit with the call wrapped with an "if (gdb is on the path)"?
|
|
| I guess it is really not available as that system got an update.
| Note that you package does not declare any SystemRequirements. Please do
| so and mention gdb.
|
| Wrapping it in "if (gdb is on the path)" seems a good solution.
Seconded esp as some systems may have lldb instead of gdb, or neither.
Adding a simple `if (nzchar(Sys.which("gdb")))` should get you there.
Dirk
Note that also
1. The machine does not have R on the path (but Rdev)
2. you need to use a current pandoc. Citing Professor Ripley: "The
platforms failing are using pandoc 3.1.6 or (newly updated, M1mac) 3.1.6.1"
Best,
Uwe Ligges
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] gdb availability on r-devel-linux-x86_64-fedora-gcc
On 12.08.2023 15:10, Jamie Lentin wrote:
Hello list,
Our package gadget3[0] has just started failing the "donttest"
additional check[1] on r-devel-linux-x86_64-fedora-gcc, specifically:-
> # Build the model in an isolated R session w/debugger
> writeLines(TMB::gdbsource(g3_tmb_adfun(cpp, compile_flags = "-g",
output_script = TRUE)))
Error in system(cmd, intern = TRUE, ignore.stdout = FALSE,
ignore.stderr = TRUE) :
error in running command
Calls: writeLines -> -> system
Execution halted
The system call in question is done by the TMB package[2], and not ours
to tinker with:
cmd <- paste("R --vanilla < ",file," -d gdb --debugger-args=\"-x",
gdbscript,"\"")
txt <- system(cmd,intern=TRUE,ignore.stdout=FALSE,ignore.stderr=TRUE)
My only vaguely reasonable guess is that gdb isn't available on the host
in question (certainly R will be!). How likely is this? Is it worth
trying to resubmit with the call wrapped with an "if (gdb is on the path)"?
I guess it is really not available as that system got an update.
Note that you package does not declare any SystemRequirements. Please do
so and mention gdb.
Wrapping it in "if (gdb is on the path)" seems a good solution.
Best,
Uwe Ligges
If this is a silly idea, which I suspect it is, would a resubmission
removing the example be accepted or just raise red flags? This is
obviously cheating---and it's a useful example I'd rather keep---but I'm
not sure we have many other options available to us.
This example isn't a problem when run elsewhere. The TMB package itself
isn't failing[3], but there doesn't seem to be any examples exercising
TMB::gdbsource() there.
Thanks for any help!
[0] https://CRAN.R-project.org/package=gadget3
[1] https://www.stats.ox.ac.uk/pub/bdr/donttest/gadget3.out
[2] https://github.com/kaskr/adcomp/blob/master/TMB/R/gdbsource.R#L40-L42
[3] https://cran.r-project.org/web/checks/check_results_TMB.html
__
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] Re-submission of removed package
On 21.07.2023 00:56, Ogan Mancarci wrote: I would if the maintainer really is unavailable but it is possible that it's just a rather long vacation so I'm happy to wait while, especially since the package remains available on github regardless. But just to confirm, there aren't any shorter term workarounds that'd bring the package back without changing maintainers? If so I will give a bit more time before re-submitting with myself as the maintainer. Right. Best, Uwe Ligges Cheers, Ogan On Thu, Jul 20, 2023 at 2:16 PM Ivan Krylov wrote: On Thu, 20 Jul 2023 13:56:31 -0700 Ogan Mancarci wrote: I have been trying to reach the maintainer to resubmit the package after the required fixes but was unsuccessful in doing so. I have submitted the package myself but it appears that it requires approval from the creator to finalise submission which I am unsure if we'll get. What is the procedure to follow in this case? Would you like to become the maintainer instead? Here's what CRAN policy has to say: Explain any change in the maintainer’s email address and if possible send confirmation from the previous address (by a separate email to cran-submissi...@r-project.org) or explain why it is not possible. -- https://cran.r-project.org/web/packages/policies.html I think you can change the Maintainer: field and note the original maintainer being unreachable in the submission comment. I would expect it to take some time to confirm that the original maintainer is actually unavailable. -- Best regards, Ivan [[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
Re: [R-pkg-devel] issues with CRAN incoming submissions / summer break announcement
I know, this has to be removed by the sysadmins in Vienna.
Best,
Uwe
On 15.07.2023 01:05, James Lamb wrote:
Thank you as always, Uwe!
By the way, the warning is still up on the submission page at
https://cran.r-project.org/submit.html
<https://cran.r-project.org/submit.html>.
image.png
Just sharing in case you hadn't noticed that yet.
Cheers,
-James
On Fri, Jul 14, 2023 at 5:33 PM Uwe Ligges
<mailto:lig...@statistik.tu-dortmund.de>> wrote:
On 12.07.2023 09:40, Uwe Ligges wrote:
> Dear developers,
>
> CRAN submissions are currently partly not possible due to some
> infrastructure issues. Please so NOT contact us if you see
"Unpacking
> failed. Please make sure the tar.gz was created with R CMD build.
[...]".
>
> In addition, processing the CRAN incoming queue of packages (CRAN
> pretest) is currently delayed by 2 days.
>
> Both issues are known and CRAN sysadmins will work on the issues.
Both issues have been resolved.
Best,
Uwe Ligges
>
>
> Note that this year's CRAN submission summer break will be from
Jul 21,
> 2023 to Aug 7, 2023.
>
> Best,
> Uwe Ligges
> for the CRAN team
>
> __
> R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
__
R-package-devel@r-project.org <mailto:R-package-devel@r-project.org>
mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
--
James Lamb
GitHub <https://github.com/jameslamb> | Twitter
<https://twitter.com/_jameslamb> | LinkedIn
<https://www.linkedin.com/in/jameslamb1/>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] issues with CRAN incoming submissions / summer break announcement
On 12.07.2023 09:40, Uwe Ligges wrote: Dear developers, CRAN submissions are currently partly not possible due to some infrastructure issues. Please so NOT contact us if you see "Unpacking failed. Please make sure the tar.gz was created with R CMD build. [...]". In addition, processing the CRAN incoming queue of packages (CRAN pretest) is currently delayed by 2 days. Both issues are known and CRAN sysadmins will work on the issues. Both issues have been resolved. Best, Uwe Ligges Note that this year's CRAN submission summer break will be from Jul 21, 2023 to Aug 7, 2023. Best, Uwe Ligges for the CRAN team __ 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-pkg-devel] issues with CRAN incoming submissions / summer break announcement
Dear developers, CRAN submissions are currently partly not possible due to some infrastructure issues. Please so NOT contact us if you see "Unpacking failed. Please make sure the tar.gz was created with R CMD build. [...]". In addition, processing the CRAN incoming queue of packages (CRAN pretest) is currently delayed by 2 days. Both issues are known and CRAN sysadmins will work on the issues. Note that this year's CRAN submission summer break will be from Jul 21, 2023 to Aug 7, 2023. Best, Uwe Ligges for the CRAN team __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Questions regarding a new (seperated package) and how to submit them to cran
On 26.06.2023 02:52, Bernd.Gruber wrote: Thanks, just to make sure: In the policy I find the entry: Additional_repositories: You can use this for CRAN-style repositories. Not for other inds of storage. In that case you need to decalre it as written text in the Description field. Best, Uwe Ligges The ‘Additional_repositories’ field is a comma-separated list of repository URLs where the packages named in the other fields may be found. It is currently used by R CMD check to check that the packages can be found, at least as source packages (which can be installed on any platform). And here I would have to provide an url that links to the tar.gz file of the package, or can I also provide The ‘Additional_repositories’ field is a comma-separated list of repository URLs where the packages named in the other fields may be found. It is currently used by R CMD check to check that the packages can be found, at least as source packages (which can be installed on any platform). github::green-striped-gecko/dartR.popgenomics similar to the Remotes: field (which I think is not possible to use). Thanks, == Dr Bernd Gruber )/_ _.--..---"-,--c_ Professor Ecological Modelling \|..' ._O__)_ Tel: (02) 6206 3804 ,=._.+ _ \..--( / Fax: (02) 6201 2328 \\.-''_.-' \ ( \_ Institute for Applied Ecology `''' `\__ /\ Faculty of Science and Technology ') University of Canberra ACT 2601 AUSTRALIA Email: bernd.gru...@canberra.edu.au<mailto:bernd.gru...@canberra.edu.au> WWW: bernd-gruber<https://researchprofiles.canberra.edu.au/en/persons/bernd-gruber> Australian Government Higher Education Provider Number CRICOS #00212K NOTICE & DISCLAIMER: This email and any files transmitted with it may contain confidential or copyright material and are for the attention of the addressee only. If you have received this email in error please notify us by email reply and delete it from your system. The University of Canberra accepts no liability for any damage caused by any virus transmitted by this email. ========== From: Uwe Ligges Sent: Sunday, 25 June 2023 20:51 To: Bernd.Gruber Cc: r-package-devel@r-project.org Subject: Re: [R-pkg-devel] Questions regarding a new (seperated package) and how to submit them to cran On 25.06.2023 09:00, Bernd.Gruber wrote: Hi, Thanks for the advice. Still not 100% sure if that is okay to submit to CRAN. As mentioned I have new packages that have others in the suggest (and yes the examples/tests run fine by making the dependent), But if I have a package that is not yet on CRAN in the suggest I see that running winbuilder. Suggests or Enhances not in mainstream repositories: dartR.sim If it is not in a mainstream repo, you can declare where users can get it from, see the explanation in the CRAN policies how to declare it. * checking package namespace information ... OK * checking package dependencies ... NOTE Package suggested but not available for checking: 'dartR.sim' This is OK, once the former is explained. Best, Uwe Ligges Can I explain when I submit that dartR.sim will be there (as mentioned the examples run fine), but obviously is not yet on CRAN. I assume the same would happen if I put the new packages in Enhances… Regards, Bernd From: Thierry Onkelinx mailto:thierry.onkel...@inbo.be>> Sent: Friday, June 23, 2023 5:51 PM To: Simon Urbanek mailto:simon.urba...@r-project.org>> Cc: Bernd.Gruber mailto:bernd.gru...@canberra.edu.au>>; r-package-devel@r-project.org<mailto:r-package-devel@r-project.org> Subject: Re: [R-pkg-devel] Questions regarding a new (seperated package) and how to submit them to cran Dear Bernd, You could contact the maintainer of the spatstat package. They did the same thing (splitting a large package into several smaller ones) a few years ago. Having the base package suggesting an add-on and the add-on depending on or suggesting the base package might create an unwanted loop. Best regards, ir. Thierry Onkelinx Statisticus / Statistician Vlaamse Overheid / Government of Flanders INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND FOREST Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance thierry.onkel...@inbo.be<mailto:thierry.onkel...@inbo.be<mailto:thierry.onkel...@inbo.be%3cmailto:thierry.onkel...@inbo.be>> Havenlaan 88 bus 73, 1000 Brussel www.inbo.be<http://www.inbo.be><http://www.inbo.be<http://www.inbo.be>> /// To ca
Re: [R-pkg-devel] Convention or standards for using header library (e.g. Eigen)
On 24.06.2023 19:44, Dirk Eddelbuettel wrote: On 24 June 2023 at 21:35, Stephen Wade wrote: | Doesnt seem like the system package is worth it. Should the convention | simply be to bundle the headers in the package then? What about package | size - is there some limit to the size of included libraries/headers to | consider for CRAN? Here is one (drastic) example: $ du -csh /usr/local/lib/R/site-library/BH 156M/usr/local/lib/R/site-library/BH 156Mtotal $ Of course one should always try to keep software as small as possible and not waste space. For binary packages, we are aware that some packages are large for the reason Dirk explains. CRAN typically does not complain here, although there are cases where we have to consider if it makes sense to distribute that huge software is system libraries may be available. The size restriction that applies for CRAN packages is the 5MB threshold for the source package size. Best, Uwe Ligges Note that the package was smaller when it started (in 2013). (Note that the last time I checked its size, the largest (not just headers) package I know of on CRAN still was about twice as large still.) Anyway: as you are starting to see, this is a somewhat complex problem. Header packages are one approach. _Writing R Extensions_ mentions pure header packages and name-checks my packages BH, RcppArmadillo and RcppEigen in Section 1.1.3. I once wrote a short paper on this [1] (also a vignette [2]) where I more or less recommend header packages because compiled ones are so much harder. Recognise for example that a) no cross-OS way to check for packages exists (though pkg-config comes close), b) no general package managers exist, c) configure and cmake come close (but cmake is also an added system requirement; and configure is a no-show on Windows) and d) even within a given OS and release you may have very different versions. Lastly also: e) some packages (RcppEigen is an example) have patches the system library would not have applied (!!). So to me a simplified view is that just as R "abstracts away" POSIX so that we can always say e.g. 'dir.exists(path)' no matter where R runs, having a package with headers ensure we get a consistent _and reliable_ compilation experience from client packages. This matters. Now, there are clearly downsides. With my Debian maintainer hat on, I have to defend including Armadillo withon RcppArmadillo because the distro has it too (but then version skew ie d) above and ease of use and consistency etc dominate so we continue to ship RcppArmadillo). At the same time, at CRAN we have needless duplications. For example, my RcppCCTZ package was the first to offer the nice (Google made but not a Google 'product') CCTZ library for R use (starting in 2015). But when I last checked a year or so ago, four other packages now included redundant extra copies. Also happens with Eigen. Not great. On the other side, packages with full (included or not) libraries work too, but they are more effort to portably provide them, to explain to users where to get them and keep them current and so. It is hard (or even impossible) for R to fill in as a _general system_ package manager across all OSs and deployments. There is a new kid on this block [3] we are starting to use at work, and which may help in time across the platforms that R uses. To be seen... So to sum up: I think header packages are great, and I maintain a few, both large and small in size. I would encourage you to try them. For RcppEigen, you can just use LinkingTo: to gets its headers. Some 400+ packages rely on it. (And its over 1000 for Armadillo now, and over 300 for BH.) Hth, Dirk [1] https://arxiv.org/abs/1911.06416 [2] https://cran.r-project.org/web/packages/Rcpp/vignettes/Rcpp-libraries.pdf [3] https://vcpkg.io/en/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Questions regarding a new (seperated package) and how to submit them to cran
On 25.06.2023 09:00, Bernd.Gruber wrote: Hi, Thanks for the advice. Still not 100% sure if that is okay to submit to CRAN. As mentioned I have new packages that have others in the suggest (and yes the examples/tests run fine by making the dependent), But if I have a package that is not yet on CRAN in the suggest I see that running winbuilder. Suggests or Enhances not in mainstream repositories: dartR.sim If it is not in a mainstream repo, you can declare where users can get it from, see the explanation in the CRAN policies how to declare it. * checking package namespace information ... OK * checking package dependencies ... NOTE Package suggested but not available for checking: 'dartR.sim' This is OK, once the former is explained. Best, Uwe Ligges Can I explain when I submit that dartR.sim will be there (as mentioned the examples run fine), but obviously is not yet on CRAN. I assume the same would happen if I put the new packages in Enhances… Regards, Bernd From: Thierry Onkelinx Sent: Friday, June 23, 2023 5:51 PM To: Simon Urbanek Cc: Bernd.Gruber ; r-package-devel@r-project.org Subject: Re: [R-pkg-devel] Questions regarding a new (seperated package) and how to submit them to cran Dear Bernd, You could contact the maintainer of the spatstat package. They did the same thing (splitting a large package into several smaller ones) a few years ago. Having the base package suggesting an add-on and the add-on depending on or suggesting the base package might create an unwanted loop. Best regards, ir. Thierry Onkelinx Statisticus / Statistician Vlaamse Overheid / Government of Flanders INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND FOREST Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance thierry.onkel...@inbo.be<mailto:thierry.onkel...@inbo.be> Havenlaan 88 bus 73, 1000 Brussel www.inbo.be<http://www.inbo.be> /// To call in the statistician after the experiment is done may be no more than asking him to perform a post-mortem examination: he may be able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher The plural of anecdote is not data. ~ Roger Brinner The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data. ~ John Tukey /// [https://inbo-website-prd-532750756126.s3-eu-west-1.amazonaws.com/inbologoleeuw_nl.png]<https://www.inbo.be> Op vr 23 jun 2023 om 06:52 schreef Simon Urbanek mailto:simon.urba...@r-project.org>>: Bernd, the sequence in which you submit doesn't matter - the packages have to work regardless of the sequence. Suggests means that the dependency is optional, not that it can break tests. You have to skip the tests that cannot be run due to missing dependencies (see 1.1.3.1<http://1.1.3.1> in R-exts) Cheers, Simon On Jun 23, 2023, at 2:35 PM, Bernd.Gruber mailto:bernd.gru...@canberra.edu.au>> wrote: Hi, I have a question regarding the separation of a package into smaller pieces (to avoid long testing/installation times and more important to avoid to many dependencies) I am the maintainer of an R package (dartR) which has grown and is now at the limit in terms of testing/run time and also dependencies. To further develop the package we started to break the package into smaller packages namely Two core packages (dartR.base and dartR.data) and here dartR.base has dartR.data in the depends. (dartR.base is 60% of the previous package) and dartR.data is our data.package for test data (dartR.data is already on CRAN) Next to the two core packages we also have 3 more addon packages that deal with specialised analysis dartR.sim dartR.spatial dartR.popgenomics. Those packages depend on dartR.base and dartR.data. All addon packages and core packages should have the other addon packages as suggests, hence here comes the question. How do I submit the packages? All of them at once? Or step by step. If I submit step by step (e.g. dartR.base) it obviously cannot have the other dartR addon packages as suggests (cannot be tested and will break the CRAN tests). So would be the correct way to: Submit dartR.base (without dartR.sim, dartR.spatial and dartR.popgenomics in the suggest.) Then submit dartR.sim, then dartR.spatial and finally dartR.popgenomics (all without suggests of the other packages) And finally update all packages (only their description file and add the suggests once they are on CRAN). Hope that makes sense and thanks in advance, Bernd __ R-package-devel@r-project.org<mailto:R-package-devel@r-project.org> mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel<
Re: [R-pkg-devel] NOTE about missing package ‘emmeans’ on macos-x86_64
On 23.06.2023 11:27, Helmut Schütz wrote: Dear all, since a while (January?) we face NOTEs in package checks (https://cran.r-project.org/web/checks/check_results_PowerTOST.html): Version: 1.5-4 Check: package dependencies Result: NOTE Package suggested but not available for checking: ‘emmeans’ Flavor: r-release-macos-x86_64 Version: 1.5-4 Check: Rd cross-references Result: NOTE Package unavailable to check Rd xrefs: ‘emmeans’ Flavor: r-release-macos-x86_64 First I thought that ‘emmeans’ is not available for macos-x86_64 on CRAN. However, ‘emmeans’ itself passed all checks (https://cran.r-project.org/web/checks/check_results_emmeans.html). Since we want to submit v1.5-5 of PowerTOST soon, any ideas? Please go ahead. Simon rarely updates the check results, so I guess this was a coincidence at the time and never got updated. I'd ignore this one. Best, Uwe Ligges Helmut __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Change package name
On 20.06.2023 18:00, Dirk Eddelbuettel wrote: Hi William, On 20 June 2023 at 16:06, William Becker wrote: | I am the maintainer of a package which is unfortunately involved in a complicated dispute regarding its intellectual property (since the package was partly built under a contract with an organisation), but also the "branding" of the package, i.e. the name. | | The story is long and complicated, but suffice to say that the name of the package is apparently creating a misleading connection with the organisation, and this is causing difficulties on both sides. | | I am aware that changing the name of a package is very disruptive, and I am not considering it lightly. However just for information at this stage, I wonder if anyone could tell me whether packages have ever changed names on CRAN, what the rules are in these cases, and if there is any advice for minimising the disruption. | | To reiterate, I am not (yet) planning to do this, but exploring options and looking for advice. You presented the reasoning convincingly and are aware of the general "we would rather not do this" sentiment. Ultimately, this (as so often) is CRAN's call so you have to do that (directly and not via this list). My sense is that you have a case but only CRAN can tell. Yes, CRAN will accept this case. Best, Uwe Ligges Good luck, Dirk __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Intrinsic UTF-8 use in aspired CRAN package
On 18.05.2023 10:03, Martin Maechler wrote:
Schuhmacher, Dominic
on Wed, 17 May 2023 12:05:49 + writes:
> Dear list, I have a package
> https://github.com/dschuhmacher/kanjistat whose very
> purpose depends on working with Japanese kanji characters
> (in UTF-8 encoding). Such characters appear vitally in the
> data sets, examples, tests, the vignette and the .Rd
> files.
> My package checks fine with devtools::check on my system
> and via Github Actions produced with
> usethis::use_github_action_check_standard(). However, I
> would like to release the package on CRAN, and running R
> CMD check --as-cran gives me a number of headaches, mainly
> related to the production of pdf documents via latex as it
> seems to be not so easy to convince latex to typeset
> Japanese, see
> https://www.overleaf.com/learn/latex/Japanese
> For the vignette, I can set in the Rmarkdown file
> pdf_document: latex_engine: lualatex includes: in_header:
> preamble.tex and in the file preamble.tex
> \usepackage{luatexja} \usepackage{microtype} This gives me
> a pdf-vignette that looks and checks fine (except that the
> abovementioned GitHub Actions don't seem to find lualatex,
> which is why the pdf output is commented out in the main
> branch on GitHub).
> Unfortunately, I fail to find a similar solution for the
> pdf manual. R CMD check yields
> --
> checking PDF version of manual ... WARNING LaTeX errors
> when creating PDF version. This typically indicates Rd
> problems. LaTeX errors found: ! Package inputenc Error:
> Unicode character 冷 (U+51B7) (inputenc) not set up for
Can you send me a minimal example package with these characters in an Rd
file?
Best,
Uwe Ligges
> use with LaTeX. [and many more of the same] * checking
> PDF version of manual without index ... ERROR
> --
> It seems that the pdf manual is generated by first
> producing a texinfo file and then running texi2dvi. From
>
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Inserting-Unicode.html
> I take the message that texinfo does not do Japanese... Is
> there any way to work around the use of texinfo and use
> lualatex (with a preamble) instead? If not, is there a way
> to keep the UTF-8 encoded characters in the html help (I
> think this is very useful for the user!) and still produce
> a pdf that passes the check, e.g. by replacing the kanji
> characters automatically by their codepoints (or even a
> generic placeholder symbol) when generating the pdf
> manual?
I cannot help much more,
but be assured that texinfo is *not* used in the process
It's just a "historical coincidence" that texi2dvi , a "simple"
shell script, typically comes from the texinfo ("software
package", i.e., in Linux distributions the texi2dvi command
(shell script, see above) is provided by the 'texinfo'
(Debian/Ubuntu/..) package
man texi2dvi tells you about a sleuth of environment variables,
notably PDFLATEX TEX etc and I guess you can just set one of
these to 'lualatex' .. .. and of course lualatex must be
findable on the CRAN servers but I'd bet that to be the case.
Best,
Martin
> Any thoughts and suggestions on this would be greatly
> appreciated! I think/hope then that the remaining problems
> in R CMD check are acceptable to the CRAN team given the
> nature of my package. They are:
> 1. Examples and tests fail if the check is not run in an
> UTF-8 locale.
> 2. checking data for non-ASCII characters ... NOTE Note:
> found 111752 marked UTF-8 strings
> Many thanks, Dominic Schuhmacher
> __
> 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] help fixing CRAN package sos
On 16.05.2023 14:02, Spencer Graves wrote:
On 5/16/23 6:06 AM, Uwe Ligges wrote:
On 16.05.2023 01:46, Spencer Graves wrote:
Hello, All:
The sos package is failing some CRAN checks, complaining:[1]
LaTeX errors:
! Missing $ inserted.
$
l.303 {\tt pspline_
checker} in the
I can only guess this is part of the response you got from some sos
request? I cannot reproduce it currently.
So check:
Does your package pass check if some function names including an
underscore in the name is returned from an sos request?
Hi, Uwe et al.:
Thanks, Uwe, for your reply.
It's complaining about something in a vignette that has been part
of the package since it appeared in The R Journal in Volume 1/2 in
2009. I received an email from Prof. Ripley complaining that it
reported problems ("WARN") on some of the CRAN checks. When I asked,
Prof. Ripley reply's reply included:
>> l.303 {\tt pspline_
>> checker} in the
>> ! ==> Fatal error occurred, no output PDF file produced!
>>
>> Underlines need to be escaped in LaTeX. And as your results depend on
>> Internet downloads,
>>
>> "Packages which use Internet resources should fail gracefully with an
>> informative message if the resource is not available or has changed
>> (and not give a check warning nor error)."
>>
>> applies: you need to anticipate that the results might include
>> underlines.
I don't know how to detect, let alone fix the "Underlines" that
"need to be escaped in LaTeX."
If you receive an output, postprocess it via
gsub("_", "_", output)
Regarding the other issue that "Packages which use Internet
resources should fail gracefully with an informative message if the
resource is not available or has changed (and not give a check warning
nor error)", I assume I should wrap in "try" all tests in *.Rd files
that access the Internet and make sure that they don't fail "R CMD
check" if the Internet is not available.
Yes.
Best,
Uwe Ligges
Comments?
Thanks again,
Spencer Graves
p.s. Yesterday I remember I got "WARN" on three of six CRAN checks
against r-devel on different platforms and NOTE on four of the seven
other CRAN checks. Today I see "WARN" on only two. If I just wait,
these "WARN" problems may go away by themselves. However, Prof. Ripley
gave me other problems to fix, and I want to support our kind, smart and
generous English professor.
Best,
Uwe Ligges
! Emergency stop.
$
l.303 {\tt pspline_
checker} in the
! ==> Fatal error occurred, no output PDF file produced!
--- failed re-building 'sos.Rnw'
I can NOT replicate these locally nor with GitHub action, and
I failed to find 'psp' in 'sos.Rnw'.[2] This raises two issue:
OBVIOUS: What can I do to fix this error, or at least to understand
it better?
SUBTLE: How can I configure "github action", so it can replicate the
errors reported on CRAN?
Thanks,
Spencer
[1]
https://cran.r-project.org
[2]
https://github.com/sbgraves237/sos
Forwarded Message
Subject: Re: CRAN package sos
Date: Sun, 14 May 2023 14:46:06 +0100
From: Prof Brian Ripley
Reply-To: CRAN
To: Spencer Graves
CC: c...@r-project.org
On 12/05/2023 13:03, Spencer Graves wrote:
Hello, All:
You have just spammed my personal email address, contrary to the CRAN
policy and done so deliberately and/or recklessly, overriding the
Reply-To header.
Is MASS being withdrawn along with multiple other packages
(mgcv, survival, boot, lattice)?
Not so. And that was a failure to do your own homework as you should
have looked on CRAN to see that they are still available.
Further
options(repos=c(CRAN="http://cran.cnr.berkeley.edu;))
does not respect the user's choice of repository: that seems to make
re-making it unreasonably slow. On my very fast MacBook Pro
* checking re-building of vignette outputs ...^R
[26s/265s] OK
so it is waiting 90% of the time.
That's responsible for 3 of the 4 'warnings' listed there.
The warning for r-devel-linux-x86_64-fedora-gcc says "LaTeX errors:
! Missing $ inserted ... Fatal error occurred, no output PDF file
produced! ... Vignette re-building failed."
These all sound to me like operating system errors. If
there's something here I should do, I could use help in
understanding what.
Do read the message -- it is a LaTeX error in the LaTeX code your
package's vignettes generates.
LaTeX errors:
! Missing $ inserted.
$
l.303 {\tt pspline_
checker} in the
! Emergency stop.
$
l.303 {\tt pspline_
check
Re: [R-pkg-devel] help fixing CRAN package sos
On 16.05.2023 01:46, Spencer Graves wrote:
Hello, All:
The sos package is failing some CRAN checks, complaining:[1]
LaTeX errors:
! Missing $ inserted.
$
l.303 {\tt pspline_
checker} in the
I can only guess this is part of the response you got from some sos
request? I cannot reproduce it currently.
So check:
Does your package pass check if some function names including an
underscore in the name is retunred from an sos request?
Best,
Uwe Ligges
! Emergency stop.
$
l.303 {\tt pspline_
checker} in the
! ==> Fatal error occurred, no output PDF file produced!
--- failed re-building 'sos.Rnw'
I can NOT replicate these locally nor with GitHub action, and I
failed to find 'psp' in 'sos.Rnw'.[2] This raises two issue:
OBVIOUS: What can I do to fix this error, or at least to understand it
better?
SUBTLE: How can I configure "github action", so it can replicate the
errors reported on CRAN?
Thanks,
Spencer
[1]
https://cran.r-project.org
[2]
https://github.com/sbgraves237/sos
Forwarded Message
Subject: Re: CRAN package sos
Date: Sun, 14 May 2023 14:46:06 +0100
From: Prof Brian Ripley
Reply-To: CRAN
To: Spencer Graves
CC: c...@r-project.org
On 12/05/2023 13:03, Spencer Graves wrote:
Hello, All:
You have just spammed my personal email address, contrary to the CRAN
policy and done so deliberately and/or recklessly, overriding the
Reply-To header.
Is MASS being withdrawn along with multiple other packages
(mgcv, survival, boot, lattice)?
Not so. And that was a failure to do your own homework as you should
have looked on CRAN to see that they are still available.
Further
options(repos=c(CRAN="http://cran.cnr.berkeley.edu;))
does not respect the user's choice of repository: that seems to make
re-making it unreasonably slow. On my very fast MacBook Pro
* checking re-building of vignette outputs ...^R
[26s/265s] OK
so it is waiting 90% of the time.
That's responsible for 3 of the 4 'warnings' listed there. The
warning for r-devel-linux-x86_64-fedora-gcc says "LaTeX errors:
! Missing $ inserted ... Fatal error occurred, no output PDF file
produced! ... Vignette re-building failed."
These all sound to me like operating system errors. If there's
something here I should do, I could use help in understanding what.
Do read the message -- it is a LaTeX error in the LaTeX code your
package's vignettes generates.
LaTeX errors:
! Missing $ inserted.
$
l.303 {\tt pspline_
checker} in the
! Emergency stop.
$
l.303 {\tt pspline_
checker} in the
! ==> Fatal error occurred, no output PDF file produced!
Underlines need to be escaped in LaTeX. And as your results depend on
Internet downloads,
"Packages which use Internet resources should fail gracefully with an
informative message if the resource is not available or has changed (and
not give a check warning nor error)."
applies: you need to anticipate that the results might include underlines.
Thanks,
Spencer Graves
m: 1-408-655-4567
On 5/12/23 1:38 AM, Prof Brian Ripley wrote:
Dear maintainer,
Please see the problems shown on
<https://cran.r-project.org/web/checks/check_results_sos.html>.
Please correct before 2023-05-26 to safely retain your package on CRAN.
The CRAN Team
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package
On 03.05.2023 23:00, Simon Urbanek wrote:
On May 4, 2023, at 3:36 AM, Martin Morgan wrote:
CRAN is fine with Bioconductor Depends: and Imports: dependencies, as
previously mentioned. This is because the CRAN maintainers explicitly configure
their system to know about Bioconductor package repositories.
That is not exactly true (at least not for all maintainers ;)). Bioconductor
packages are installed on as-needed (best-effort) basis and it is a manual
process.
Apparently for MacOS.
On Fedora/Debian/WIndows we auto install from BioC. (actually, on
Windows all BioC software packages are preinstalled).
Best,
Uwe Ligges
Ideally, Bioconductor packages would be in Suggests, because if they are not,
the package binary will be effectively broken for most users as they cannot
install it without additional steps (and no stable state can be guaranteed,
either). That's why I believe someone was suggesting a pre-flight check that
alerts the user to such situation and prints instructions to remedy it (e.g.,
to use setRepositories()) as the majority of users will have no idea what's
going on.
Cheers,
Simon
Users face a different challenge -- many users will not have identified (e.g.,
via `setRepositories()` a Bioconductor repository, so when they try to install
your package it will fail in a way that you have no control over -- a generic
message saying that the Bioconductor dependencies was not found.
You could mitigate this by advertising that your CRAN package should be installed via
`BiocManager::install("")`, which defines appropriate
repositories for both CRAN and Bioconductor, but there is no way to unambiguously communicate
this to users.
Martin
From: R-package-devel on behalf of Ruff,
Sergej
Date: Wednesday, May 3, 2023 at 11:13 AM
To: Dirk Eddelbuettel
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the
Description File of my R Package
Thank you, Dirk.
I see your dependencies are Suggested. I know that Suggested dependencies
should be conditional.
Do you know if Non-Cran (Bioconductor) packages need to be conditional? Do you
have any experiece regarding Non-CRAN Dependencies
and how to handle them?
I believe Duncan Murdoch's experience and opinion regarding that topic, but i
take any second and third opinion to be sure.
Thank you for your help.
Sergej
Von: Dirk Eddelbuettel
Gesendet: Mittwoch, 3. Mai 2023 16:22:09
An: Ruff, Sergej
Cc: Duncan Murdoch; Ivan Krylov; r-package-devel@r-project.org
Betreff: Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the
Description File of my R Package
Sergej,
Please consider:
- there are nearly 20k CRAN packages
- all of them are mirrored at https://github.com/cran so you can browse
- pick any one 'heavy' package you like, Seurat is a good example; there
are other examples in geospatial or bioinformatics etc
- you can browse _and search_ these to your hearts content
Here is an example of mine. In RcppArmadillo, years ago we (thanks to fine
Google Summer of Code work by Binxiang Ni) added extended support for sparse
matrices pass-through / conversione from R to C++ / Armadillo and back. That
is clearly an optional feature as most uses of (Rcpp)Armadillo use dense
matrices. So all code and test code is _conditional_. File DESCRIPTION has
Suggests: [...], Matrix (>= 1.3.0), [...], reticulate, slam
mostly for tests. I.e. We have very little R code: in one single file
R/SciPy2R.R we switched to doing this via reticulate and opee the function
with
if (!requireNamespace("reticulate", quietly=TRUE)) {
stop("You must install the 'reticulate' package (and have SciPy).",
call.=FALSE)
}
after an actual deprecation warning (as there was scipy converter once).
Similarly, the testsuites in inst/tinytests/* have several
if (!requireNamespace("Matrix", quietly=TRUE)) exit_file("No Matrix
package")
as well as
if (!requireNamespace("reticulate", quietly=TRUE)) exit_file("Package reticulate
missing")
if (!packageVersion("reticulate") >= package_version("1.14"))
exit_file("SciPy not needed on newer reticulate")
and tests for slam (another sparse matrix package besides the functionality
in Matrix).
Hopefully this brief snapshot gives you an idea. There are (likely!!)
thousandss of examples you can browse, and I am sure you will find something.
If you have further (concrete) questions please do not hesitate to use the
resource of this list.
Cheers (or I should say "mit Braunschweiger Gruessen nach Hannover),
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/
Re: [R-pkg-devel] package not passing automatic checks: no clue as to what is causing 2 notes
Indeed, a hicc up of the Windows builder. Should be resolved. Best, Uwe Ligges On 12.04.2023 10:48, Gianmarco Alberti wrote: Hello, Thanks for your prompt advices. I am not an expert…. I have sent an email to explain that those are likely to be issues on the CRAN’s end, and to inform that I would not mind to wait a while and re-do the entire submission procedure. Thank you again Gm -- Dr Gianmarco Alberti | Lecturer in Spatial Forensics BA, MA, PhD (Udine) - Coordinator of the BA dissertations Department of Criminology - Faculty for Social Wellbeing Room 332, Humanities B (FEMA) University of Malta Msida - MSD 2080 (Malta) +356 2340 3718 Google Scholar: https://scholar.google.com/citations?user=tFrJKQ0J=en ResearchGate: https://www.researchgate.net/profile/Gianmarco_Alberti4 Academia: https://malta.academia.edu/GianmarcoAlberti movecost: https://CRAN.R-project.org/package=movecost chisquare: https://CRAN.R-project.org/package=chisquare CAinterprTools: https://CRAN.R-project.org/package=CAinterprTools On 12 Apr 2023, 10:16 +0200, Ivan Krylov , wrote: В Wed, 12 Apr 2023 10:05:32 +0200 Gianmarco Alberti пишет: 'CreateProcess' failed to run 'd:\rtools43\x86_64-w64-mingw32.static.posix\bin\tidy.exe -language en -qe --drop-empty-elements no D:\temp\Rtmp29JsRe\file2426857b24734' This is a (transient?) problem on the machine running the check: something completely prevented HTML Tidy from running, even before the process would have tried to load the required DLLs. Nothing to do with your package. * checking for detritus in the temp directory ... NOTE Found the following files/directories: 'lastMiKTeXException' I think this is a false positive too. Some other package may have failed to compile its PDF documentation (at the same time?), which caused MiKTeX to create this file in the temp directory. Your PDF manual check resulted in an OK. Does the automatic e-mail include the instructions on where to reply with this explanation? -- Best regards, Ivan [[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
Re: [R-pkg-devel] Changing R Package Maintainer
On 07.04.2023 21:14, Andrew Simmons wrote: Hi, I'm changing my name and my email address. I've got an update I'd like to submit to CRAN, I've changed my name and email in my DESCRIPTION. I couldn't find any details about changing maintainers in the R manuals It is in the CRAN policies. unfortunately. Someone online said to just submit the update, CRAN will send one email to the new address confirming the submission, and another to the old address confirming the new maintainer. Yes, that's true. Someone else said to email CRAN from the old address about the new maintainer and their address, and wait for a response of approval before submission. It was unclear if that would be cran-submissi...@r-project.org or c...@r-project.org, but I'd guess the first. THis is also a true option. Personally I'd prefer the first way. Has anyone else done this before or does anyone know the best procedure? Also, given that this isn't a transfer of ownership, I'm still the same person with a different name, would that make this process easier? Same process as we do not know whether it is the same person behind the other mail address. Best, Uwe Ligges Thank you! [[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
Re: [R-pkg-devel] What checks are required before uploading a package to CRAN?
On 05.04.2023 09:17, Ivan Krylov wrote: On Tue, 4 Apr 2023 14:28:52 -0600 John Lawson wrote: ERROR: Access to the path 'C:\Inetpub\ftproot\R-devel\daewr_1.2-9.tar.gz' is denied. (perhaps you uploaded already and the file has not been processed yet?) It has been 4 days since I uploaded the file to R-release, and I get automatic emails every other day from Uwe Ligges telling me my package has been checked and built. Interesting, you shouild receive one mail for each upload. Can yoiu tell me when you got an unexpected one? Can you forward it to me? I do not see a package in any of the queues right now. Best, Uwe Ligges This might need some help from Uwe Ligges to resolve the package queue problems. What checks are required before uploading the package tar.gz file to the cran.r-project.org/submit.html page? The policy strongly recommends checking the package with R-devel but doesn't require you to use Win-Builder. You can get R-devel for Windows from <https://cran.r-project.org/bin/windows/base/rdevel.html> and run R CMD check from that. If you don't want to install additional software, you can use R-hub <https://builder.r-hub.io/advanced> and other package checking services. They don't run exactly the same software on exactly the same hardware as CRAN checks, but they do fulfil the requirement to have your package checked by R-devel. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] correcting errors in an existing package
On 02.04.2023 12:12, Michael Dewey wrote: Comment in-line On 02/04/2023 06:37, Ivan Krylov wrote: On Fri, 31 Mar 2023 16:51:40 -0400 Dennis Boos wrote: Also, I keep getting the message in the Rstudio check WARNING 'qpdf' is needed for checks on size reduction of PDFs but I got the latest versions of R and Rstudio and was able to get qpdf to install and loaded with library(qpdf), but Rstudio still gives that message. Almost there. The 'qpdf' package interfaces to the same code that the 'qpdf' command line tool uses to do its job. R CMD check uses the latter, not the former. It looks like you're on Windows, so you need to install Rtools in order to get a compatible version of 'qpdf': https://cran.r-project.org/bin/windows/Rtools/rtools43/rtools.html I always get the warning about qpdf (on Windows) but it does not seem to be a problem on CRAN or winbuilder. You have to have qpdf installed and on your PATH. Best, Uwe Ligges __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package
The user should set the CRAN+BioC via setRepositories() and then run
install.packages() will install all dependencies automatically.
Of course, if you install from a local repository without the required
packages or from a USB drive, R cannot resolve dependencies.
Best,
Uwe Ligges
On 17.03.2023 13:29, Ruff, Sergej wrote:
Really.Whats a problem i have when all dependencies arent prei installed. I
thought the problem would be solved once my package is available on CRAN.
Here is a recent question I had regarding the same issue:
I am currently working on a r-package. I would like to submit my r package to
CRAN, but I have a question regarding dependency installations on CRAN.
I have almost finished my package, added the required dependencies to the
NAMESPACE and DESCRIPTION files as Imports, and get no errors or warnings
when running the check in Rstudio. The package runs on the pc, where I´ve built
the package, but when I install the package on a pc, where the dependencies
are not preinstalled, I get the following error:
ERROR:
dependencies 'depth', 'geometry' are not available for package 'packagename'
* removing
'C:/Users/156932/AppData/Local/Programs/R/R-4.2.1/library/packagename'
Warning in install.packages : installation of package ‘packagename’ had
non-zero exit status
The problem is that a local installation of my package (via USB-stick for
example) can´t install the dependencies from CRAN.
The package works perfectly fine, if the dependencies are preinstalled.
Now I don´t want to submit my package to CRAN if the end user gets the same
error message when installing my package.
Question: After I submit my package to CRAN, will CRAN install dependencies automatically
(via "install.packages()"), resolving the issue I have right now?
Or do I have to modify the R-package or the Description-file to make sure my
Package can install dependencies?
I provided the dependencies to the NAMESPACE-file as @ImportFrom via the
devtools::document()-function. I added the dependencies to the DESCRIPTION-file via
usethis::use_package("x",type="Imports"). The Description looks like this:
License: GPL (>= 3)
Encoding: UTF-8
LazyData: true
RoxygenNote: 7.2.3
Imports:
depth,
geometry,
graphics,
grDevices,
MASS,
mvtnorm,
nlme,
rgl,
stats
So I thought all dependencies would install automatically from CRAN? Is that
not the case?
Von: Duncan Murdoch
Gesendet: Freitag, 17. März 2023 13:15:28
An: Ruff, Sergej; Martin Morgan; Ivan Krylov
Cc: r-package-devel@r-project.org
Betreff: Re: AW: [R-pkg-devel] How to declare Bioconductor Dependencies in the
Description File of my R Package
On 17/03/2023 6:19 a.m., Ruff, Sergej wrote:
In my example I have the following lines:
### Differential expression analysis with limma
group = gl(2, n)
design = model.matrix(~ group)
fit1 = limma::lmFit(X, design)
fit = limma::eBayes(fit1)
The R CMD Check returns no Errors or Notes if Limma is pre-installed. If
limma is not pre-installed I get an error, reminding me that Limma is
not available.
That's a problem, and will cause your package to be rejected. It should
not raise an error during the tests when a suggested package is missing.
Ivan gave you good advice on how to fix this.
I'd recommend testing your package a few times on Winbuilder and fixing
things until you get clean results. That won't guarantee acceptance on
CRAN; new packages get a manual inspection as well, and they'll often
find some problem that the automatic tests don't find, e.g. stylistic
issues in the Description field of the DESCRIPTION file. Here's a note
I received recently when I submitted a new package (RmdConcord):
The Description field is intended to be a (one paragraph) description of
what the package does and why it may be useful. Please add more details
about the package functionality and implemented methods in your
Description text.
Please always write package names, software names and API (application
programming interface) names in single quotes in title and description.
e.g: --> 'R Markdown'
Please note that package names are case sensitive.
Please do not start the description with "This package", "Functions
for", package name, title or similar.
---
Duncan Murdoch
Thats the source of my worries. Will the same error appear when CRAN
checks the examples of my package? Or should I not be worried?
With regards,
Sergej
*Von:* Duncan Murdoch
*Gesendet:* Freitag, 17. März 2023 11:14:25
*An:* Ruff, Sergej; Martin Morgan; Ivan Krylov
*Cc:* r-package-devel@r-project.org
*Betreff:* Re: [R-pkg-devel] How to declare Bioconductor Dependencies in
the Description File of my R Package
On 17/03/2023 6:06 a.m., Ruff, Sergej wrote:
I was wondering how CRAN will handle Limma when run
Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package
On 17.03.2023 13:09, Ruff, Sergej wrote:
Thanks,
I thought about changing it to "Imports", but will it cause any issues when
CRAN runs checks on my package and limma isn´t available on CRAN?
No, BioC is a mainstream repository.
Best,
Uwe Ligges
Von: Ivan Krylov
Gesendet: Freitag, 17. März 2023 12:31:23
An: Ruff, Sergej
Cc: r-package-devel@r-project.org
Betreff: Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the
Description File of my R Package
В Fri, 17 Mar 2023 11:02:18 +
"Ruff, Sergej" пишет:
I would like to ask, if I need to add something to the
DESCRIPTION-file when declaring Bioconductor dependencies for CRAn
Submission.
Strictly speaking, no. Once you list limma under Suggests, it's
possible and proper to install your package using
BiocManager::install('YOUR_PACKAGE', dependencies = TRUE) and have
limma installed too, as Martin Morgan said above in the thread.
Some recommend adding biocViews:
This field is required on Bioconductor, not CRAN:
https://contributions.bioconductor.org/description.html?q=biocViews#description-biocviews
some recommend adding Remotes: bioc::limma
Not a standard R/CRAN field, only used by the remotes package:
https://remotes.r-lib.org/articles/dependencies.html
Others add Biocmanager to the suggests file
I suppose it could help a user who doesn't initially know to use
BiocManager in order to install your package, and could also be used to
install limma on behalf of your users (with their permission!), but
it's additional work, may be hard to get right (see the CRAN policy
about installing packages and touching user files), and is not required
at all.
What should I add to my Description File to make sure that limma gets
installed from Bioconductor when needed?
See Martin Morgan's e-mail above in the thread. In short, tell your
users to install your package using BiocManager::install(...,
dependencies = TRUE) if they want limma to work. They are still free to
install.packages() if they don't want limma or can set things up
themselves.
Move limma to Imports (better) or Depends (may be worse)
if you want limma to be always available, at the cost of always
requiring Bioconductor to be set up to have your package installed.
There are other ways besides BiocManager::install(), but they all
depend on the user having set up Bioconductor repos in their R session
somehow, be it BiocManager::repositories() or setRepositories().
--
Best regards,
Ivan
[[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
Re: [R-pkg-devel] Checking timings of packages
On 14.03.2023 15:43, Ivan Krylov wrote: В Tue, 14 Mar 2023 13:52:13 + Chris Brien пишет: The difficulty I am having is that I cannot be sure that the timings for r-devel-linux-x86_64-debian-gcc and r-devel-windows-x86_64 will be under 10 s, as seems to be required, if I were to resubmit the package to CRAN with the reduced examples. I would be grateful to anyone who can suggest how I might go about determining the CRAN timings without submitting the package to CRAN. I think that win-builder R-devel <https://win-builder.r-project.org/> is the same machine as the CRAN r-devel-windows-x86_64 machine (at the very Yes. Best, Uwe Ligges least, the CPU description of win-builder matches that from <https://cran.r-project.org/web/checks/check_flavors.html#r-devel-windows-x86_64>). __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] URL timeout in win-builder check: suggestions?
On 13.03.2023 15:28, Ben Bolker wrote: I have a URL in my documentation that got a timeout error from win-builder, possibly because of some kind of service provider filtering of bots (I think there was a previous issue with Cloudflare links?) I can get to it fine interactively/in a browser. This link is a harmless bit of fluff (click through if you want to see), but I don't want it causing hiccups in my CRAN submission (i.e., I could take it out if necessary but would prefer not to ...) Suggestions? Keep and submit. Best, Uwe Ligges === * checking CRAN incoming feasibility ... NOTE Maintainer: 'Ben Bolker ' Found the following (possibly) invalid URLs: URL: https://phdcomics.com/comics/archive.php?comicid=905 From: man/pvalues.Rd Status: Error Message: Operation timed out after 60010 milliseconds with 0 bytes received __ 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] OpenCL R packages on CRAN
On 13.03.2023 11:43, quirin stier wrote: Hi, I would like to ask what the current situation is regarding R packages for computations on the GPU. There are no more official CRAN packages using CUDA or OpenCL as foundation. There are only packages providing either access to OpenCL, tensorflow or similar and packages using directives in C++ via OpenMP. My aim is to provide an R package using OpenCL. However, as far as I know, such package would not run in Windows. Does CRAN accept packages which are not compatible with every os? CRAN asks for cross plattform code if possible. In some situations where it is not possible to provide cross plattform code, CRAN also accepts code that works for many (but not all) plattforms. OpenCL and Windows: Why would a package using OpenCL not work on Windows? We may have difficulties providimg binaries of the package (and checking it) as corresponding graphics hardware is not available on the build/check machines, but if possible you shopudl support that users with the required hardware can compile the package from sources on Windows, too. Best, Uwe Ligges __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] FAIL output in CRAN checks?
On 08.03.2023 19:13, Ben Bolker wrote: I don't know that I've ever seen this one before: a result of FAIL for a CRAN check. There's a WARNING which I already know about, but this build seems to get hung up on "checking re-building of vignette outputs ..." (which takes about 70/95 seconds on most other platforms) https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/lme4-00check.html Not shown anymore, I guess ome hicc up on the check machine. Or in case you download data some internet access issue? Best, Uwe Ligges Does anyone have ideas about this? Is this something I should worry about/try to diagnose and fix? (r-hub does appear to have a fedora/clang platform) For what it's worth: > rhub::platforms() Error in curl::curl_fetch_memory(url, handle = handle) : Peer certificate cannot be authenticated with given CA certificates: [builder.r-hub.io] SSL certificate problem: certificate has expired I guess I could report that ... > > cheers Ben Bolker __ 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
