[R-pkg-devel] Package submission - Issue with pandoc in R CMD check

Gábor Csárdi csardi.gabor at gmail.com
Thu Jun 22 17:23:16 CEST 2017


So, along these lines, I was thinking if we could / should build a
pandoc R package, that could just pull the right binary at install
time. Would that make sense? It is a bit unusual, but I think a lot of
users would like it, and it would help standardizing pandoc versions
and usage.

The static binary is good for 64 bit Linux, and we also have
self-contained binaries for Windows and MacOS.

(The relevant links to the Docker containers and the binaries, in case
you are interested:
https://github.com/r-hub/pandoc-builders#readme
https://files.r-hub.io/pandoc/

Gabor

On Thu, Jun 22, 2017 at 4:02 PM, Dirk Eddelbuettel <edd at debian.org> wrote:
>
> On 22 June 2017 at 16:36, Uwe Ligges wrote:
> | This should be resolved in general now.
>
> I appreciate your work on this, as well Gabor's help in providing new binaries.
>
> But correct me here if I wrong:  It still does not help with this issue as
> long as _any other pandoc binary_ is called, correct?
>
> I.e. when I run R CMD check at home on a standard Linux box, I still get an
> error.  Unless I switch to an alternate source for the file to continue to
> avoid that particular server, or unless I use an alternate pandoc binary.
>
> So just thinking out aloud: Given that a key piece of R testing now depends
> on a custom binary, should be we look into providing that binary?  Should the
> call to pandoc utilize an 'R-supplied' pandoc version?
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



More information about the R-package-devel mailing list