Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is the recommended way to run R CMD check with these containers? #11

Open
nsheff opened this issue Apr 7, 2020 · 7 comments
Open
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@nsheff
Copy link

nsheff commented Apr 7, 2020

I'm using the container bioconductor/bioconductor_docker:RELEASE_3_10.

When I try to run an R CMD check using this container, I get:

* checking PDF version of manual ... WARNING
LaTeX errors when creating PDF version.
This typically indicates Rd problems.
* checking PDF version of manual without hyperrefs or index ... ERROR
Re-running with no redirection of stdout/stderr.
Hmm ... looks like a package
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  : 
  pdflatex is not available
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  : 
  pdflatex is not available
Error in running tools::texi2pdf()

I presume this is because this container doesn't contain all the required latex stuff for building PDF manuals. That's probably by design since the latex dependencies are huge -- but in this case, what is the recommended way to do R CMD check ?

Further, running a BiocCheck in the container also fails since BiocCheck hasn't been included.

R CMD BiocCheck rigd_1.0.tar.gz 
/usr/local/lib/R/bin/Rcmd: 62: exec: BiocCheck: not found

What is the recommended way to use the containers for package building/checking? Do you think it makes sense to maintain some kind of a 'building' image that includes these prerequisites?

@nturaga
Copy link
Collaborator

nturaga commented Apr 13, 2020

Hi @nsheff ,

I'll try to get a size comparison with a devel image with things installed on it to understand what would be needed to get closer to the build machine.

But as for right now,

R CMD check --no-vignette might help. And also an image like this?

# This docker image has LaTeX to build the vignettes
FROM bioconductor/bioconductor_docker:devel

# Update apt-get
RUN apt-get update \
	&& apt-get install -y --no-install-recommends apt-utils \
	&& apt-get install -y --no-install-recommends \
	texlive \
	texlive-latex-extra \
	texlive-fonts-extra \
	texlive-bibtex-extra \
	texlive-science \
	texi2html \
	texinfo \
	&& apt-get clean \
	&& rm -rf /var/lib/apt/lists/*

## Install BiocStyle
RUN R -e 'BiocManager::install(c("BiocStyle", "BiocCheck"))'

@nturaga nturaga self-assigned this Apr 22, 2020
@nsheff
Copy link
Author

nsheff commented May 20, 2020

Hi @nturaga -- any updates on this? do you think it would make sense for Bioconductor to maintain exactly this docker image as you suggest? Because otherwise I think several of us are basically doing exactly this independently...

@lwaldron
Copy link

I think Vince has funding specifically to fully containerize the official build system, and to make it straightforward for anyone to test packages on the same container. Not sure of the status, but I fully agree on the value of having a shared build environment. I suspect in the meantime several of us have added the above code independently (e.g. https://github.com/waldronlab/bioconductor), which approximates the Linux build system adequately for most (but not 100% of) packages. I guess there's a fair ways to go to a 3-platform containerized build system for all Bioconductor packages, but that may be letting the perfect be the enemy of the good in the meanwhile.

@nsheff
Copy link
Author

nsheff commented May 26, 2020

One problem with the above approach is that for every R version, you have to have a duplicated installation of all the latex stuff, which is quite large. It would be more efficient to base the bioconductor containers on a base image that included latex, so that those layers would only have to be stored once, and multiple versions of R could live on top of that (since R is changing more rapidly than the latex stuff. Furthermore, the base latex image could probably be a useful standalone latex image.

bigger picture -- maybe eventually the PDF building stuff should be removed from R CMD check entirely. In my experience most things are moving toward HTML outputs anyway so maybe latex shouldn't be required for the default R CMD check. Unfortunately, the -no-vignettes option didn't solve the issue for me.

@nturaga
Copy link
Collaborator

nturaga commented May 29, 2020

@nsheff, @LiNk-NY and I looking into a docker-compose solution, where we have a latex installed on an ubuntu 18.04 image and we share a volume which has the tex bin with the bioconductor_docker:devel image.

@nturaga
Copy link
Collaborator

nturaga commented Jun 18, 2020

@nsheff @lwaldron

Do you have any expertise in docker-compose or sharing volumes?

https://github.com/nturaga/bioconductor-latex

The idea here is TinyTex is installed on a docker image. We share the /root/.TinyTex/ volume with the bioconductor_docker image. And if this location is added to the $PATH on the bioconductor_docker image, it should have access to the tex libraries needed to build vignettes. We do not need to have a complete installation of latex, just need TinyTex and a few libraries installed with tlmgr.

This solution will prevent the duplication issue, which you mention above. But I'm not able to get this solution to work as I wanted, and I was hoping to open up a discussion to get it to work.

Right now, the problem with what I shared on that GitHub repo is the files in the .TinyTex path won't share with my bioconductor_docker:devel container.

@nturaga
Copy link
Collaborator

nturaga commented Jun 18, 2020

Adding @LiNk-NY to the thread as he did some work on this too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants