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 <e...@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 | e...@debian.org > > ______________________________________________ > 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
