Message-ID: <CABtg=KnL9_yjv42od-YnHZNDBV-feto+m66+7_dfSx9vbFLqRA@mail.gmail.com>
Date: 2017-06-22T15:23:16Z
From: Gábor Csárdi
Subject: [R-pkg-devel] Package submission - Issue with pandoc in R CMD check
In-Reply-To: <22859.56331.656347.678483@max.eddelbuettel.com>
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