Re: Is there any chance to make mathjaxr non-mandatory in metap
Dear Wolfgang,
thanks a lot for stepping in.
On Wed, Jan 27, 2021 at 12:03:05PM +0000, Viechtbauer, Wolfgang (SP) wrote:
> I am aware of the discussion and understand the issue with the way MathJax is bundled with mathjaxr (i.e., MathJax is provided by default using minified/compressed javascript, which (rightly so imho) could be argued to not be proper source code).
>
> The minification is not something I did - I am just using how MathJax is provided by default.
I can perfectly understand this any many maintainers of R packages are
doing so with different JS libraries. Do you see any chance to use an
existing MathJax in the file system - as for instance in the Debian
package libjs-mathjax which installs its files to
/usr/share/javascript/mathjax/
in favour of the code copy shipped with your package. The Debian
procedure would be to strip your source package to remove that code copy
and instead use the system installation.
> I do intend to look into creating a non-minified version of MathJax that I can then bundle with mathjaxr. If I succeed in doing so, then there might be an issue with mathjaxr becoming too large for a CRAN package, but maybe this is something that can be discussed with the CRAN maintainers (and possibly, the minification could still happen upon installation of the source package).
While this would be another option the Debian way is to prevent code
copies anyway - so if it is feasible for you I'd be really happy if
the Debian packaged MathJax could be reused.
> To be 100% clear: I absolutely understand the concern with the minified JS and I will try to find a solution (when I have the time). However, I personally never install R packages from deb's (i.e., I always install all R packages from source directly from CRAN). R packages are so frequently updated - and for good reason - that I would never rely on what version has been bundled as a deb in the past. But that's just my personal preference.
Fair enough. I can fully understand this and as a CRAN developer I
would probably do the same. The actual reason why we are packaging more
and more CRAN and BioConductor packages is that we can define
dependencies between Debian packages. Lots of non-R packages depend
from R packages and so we have a closed set of code dependencies. We
try to make sure that at release freeze time all R packages are up to
date (that's why I'm currently worried about some remaining packages
like metap since the freeze date is coming soon). Otherwise we have
semi-automated upgrading R packages (and creating new dependencies)
which helps us to keep Debian unstable quite in sync with current CRAN -
but lagging behind from time to time when other tasks are occupying
developers. That's a perfect reason not to rely on Debian packages for
some people.
Kind regards and thanks a lot for your insight
Andreas.
--
http://fam-tille.de
Reply to: