Dear Ott
Perhaps a dumb question but does your package DESCRIPTION include a
dependency on lattice (or i,port or suggest)?
Michael
On 12/08/2025 14:58, Ott Toomet wrote:
Thanks, everyone, for responding. Here a summary of my research so
far--I do not quite understand what I am doing, but I
With all due respect, that summary was more misleading than helpful. This is
also the wrong list to discuss the matter as a few Debian packaging specific
aspects appear to be falsely seen as general R features. I reiterate that
follow-ups, if any, would really be better suited to either the r-si
Thanks, everyone, for responding. Here a summary of my research so
far--I do not quite understand what I am doing, but I spotted
a number of different issues, and I got the checks to work.
* I was not aware of the distinction between default and recommended
packages, and the fact that the latte
On Mon, 11 Aug 2025 08:47:45 -0400
Duncan Murdoch wrote:
> Regarding Dirk's "narrower" comment: I think that is really his
> decision about the docker container, not a property of R CMD check.
> R CMD check needs to be able to succeed if the only packages
> installed are the hard dependencies (D
On 11 August 2025 at 05:26, Ott Toomet wrote:
| * Is this "narrower" library path for CMD check explained somewhere?
Make your package (in a test, maybe even just tests/hello.R) do
`print(.libPaths())` and assert it is different during tests.
This has nothing to do with the Docker container (bu
lattice is a "recommended" package. Those are contributed packages, not
base packages, so they are optional, but most distributions of R include
them.
Regarding Dirk's "narrower" comment: I think that is really his
decision about the docker container, not a property of R CMD check. R
CMD c
Hmm...
I am a little bit confused.
* Is this "narrower" library path for CMD check explained somewhere?
* Isn't lattice one of the default packages (graphics depends on it iirc),
so it should be installed in any case?
Thanks, anyway. So far my tiny test package
https://github.com/otoomet/dummyp
On 11 August 2025 at 18:03, Greg Hunt wrote:
| Out of curiosity, why do they install two instances of R in a Docker
| container? On a traditional physical tin server, sure, you can't avoid
| that sort of thing, but why in Docker? I didn't see a rationale for it on
| the Rocker wiki or website.
On 10 August 2025 at 21:38, Ott Toomet wrote:
| root@f4024e015396:/# cat maxLik.Rcheck/00install.out
| * installing *source* package ‘maxLik’ ...
| ** this is package ‘maxLik’ version ‘1.6-3’
| ** using staged installation
| ** R
| ** inst
| ** byte-compile and prepare package for lazy loading
|
Out of curiosity, why do they install two instances of R in a Docker
container? On a traditional physical tin server, sure, you can't avoid
that sort of thing, but why in Docker? I didn't see a rationale for it on
the Rocker wiki or website.
Greg
On Mon, 11 Aug 2025 at 16:05, Ott Toomet wrote:
Thanks.
I thought this was the issue, and even manually deleted /usr/bin/R and
/usr/bin/Rscript, but the problem persisted. But now I am thinking that
/usr/bin/R may not be the relevant executables, the development version may
pull up something directly from /usr/lib/R/bin instead (the devel is
i
11 matches
Mail list logo
