[R-pkg-devel] Rdmacros as Suggests rather than Imports

Hi James,

| I'm writing to see if anyone has suggestions for how to handle an issue I'm
| facing with the clubSandwich package (
| https://CRAN.R-project.org/package=clubSandwich; Github repo:
| https://github.com/jepusto/clubSandwich). The package documentation uses
| the fairly new package mathjaxr (https://CRAN.R-project.org/package=mathjaxr;
| Github repo: https://github.com/wviechtb/mathjaxr) so that the help
| packages can include mathjax formulas. Using mathjaxr requires adding it as
| a dependency (in Imports) and in the Rdmacros field.
| 
| I recently learned that the Debian GNU/Linux team that handles R packaging
| has trouble with the mathjaxr package, and consequently with any package
| that has mathjaxr as a dependency. Thus, I would like to make
| mathjaxr an optional feature, moving it from Imports to Suggests.
| However, Writing R Extensions specifies that RdMacros packages must be
| listed in Imports or Depends.
| 
| Does anyone have suggestions for a potential workaround for this situation
| (short of entirely removing the use of mathjaxr)?

That is what Duncan did with rgl, from where this arose. (It's all very
inside baseball by for embedded 'minified' js files Debian 'ftpmasters'
[essentially our version of the CRAN desk accept/reject] also require full
source of the javascript file, which is not unreasonable -- but a bit of a
pain pain). Wolfgang (for mathjaxr) knows about it, and "time permitting"
packaging of mathjaxr may change. In the meantime the easiest os for you to
not use mathjaxr (I don't think the help page rendering mechanism has
optionality here) or for your corresponding Debian maintainer (CC'ed) to
patch it out (which is what I had done for the first rgl release with it).

Dirk

https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

Dirk,

Thanks very much for your input! By "patch it out" do you mean modify my
package description for the Debian distribution only? Would it work to
create a separate branch of my Github repo with modifications for the
Debian distro, and then submit that directly to Debian maintainers?

I'm sorry for my naivete here--I'm just not quite sure how to proceed.

James

Hi James,

On 22 January 2021 at 14:29, James Pustejovsky wrote:
| I'm writing to see if anyone has suggestions for how to handle an issue
I'm
| facing with the clubSandwich package (
| https://CRAN.R-project.org/package=clubSandwich; Github repo:
| https://github.com/jepusto/clubSandwich). The package documentation uses
| the fairly new package mathjaxr (
https://CRAN.R-project.org/package=mathjaxr;
| Github repo: https://github.com/wviechtb/mathjaxr) so that the help
| packages can include mathjax formulas. Using mathjaxr requires adding it
as
| a dependency (in Imports) and in the Rdmacros field.
|
| I recently learned that the Debian GNU/Linux team that handles R
packaging
| has trouble with the mathjaxr package, and consequently with any package
| that has mathjaxr as a dependency. Thus, I would like to make
| mathjaxr an optional feature, moving it from Imports to Suggests.
| However, Writing R Extensions specifies that RdMacros packages must be
| listed in Imports or Depends.
|
| Does anyone have suggestions for a potential workaround for this
situation
| (short of entirely removing the use of mathjaxr)?

That is what Duncan did with rgl, from where this arose. (It's all very
inside baseball by for embedded 'minified' js files Debian 'ftpmasters'
[essentially our version of the CRAN desk accept/reject] also require full
source of the javascript file, which is not unreasonable -- but a bit of a
pain pain). Wolfgang (for mathjaxr) knows about it, and "time permitting"
packaging of mathjaxr may change. In the meantime the easiest os for you to
not use mathjaxr (I don't think the help page rendering mechanism has
optionality here) or for your corresponding Debian maintainer (CC'ed) to
patch it out (which is what I had done for the first rgl release with it).

Dirk

--
https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

Hi James,

| Thanks very much for your input! By "patch it out" do you mean modify my
| package description for the Debian distribution only? Would it work to

And code / content! Can't just alter the DESCRIPTION if the Rd still call mathjaxr.

| create a separate branch of my Github repo with modifications for the
| Debian distro, and then submit that directly to Debian maintainers?
| 
| I'm sorry for my naivete here--I'm just not quite sure how to proceed.

I attempted to lay out two alternatives:

 i)  where you remove mathjaxr, the Debian package just follows
 ii) where you do nothing but the Debian package gets altered ("patched")
     and then differs in that only it no longer uses mathjaxr

Hth,  Dirk

https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

Hi James,

On 22 January 2021 at 15:42, James Pustejovsky wrote:
| Thanks very much for your input! By "patch it out" do you mean modify my
| package description for the Debian distribution only? Would it work to

And code / content! Can't just alter the DESCRIPTION if the Rd still call mathjaxr.

| create a separate branch of my Github repo with modifications for the
| Debian distro, and then submit that directly to Debian maintainers?
|
| I'm sorry for my naivete here--I'm just not quite sure how to proceed.

I attempted to lay out two alternatives:

  i)  where you remove mathjaxr, the Debian package just follows
  ii) where you do nothing but the Debian package gets altered ("patched")
      and then differs in that only it no longer uses mathjaxr

Hth,  Dirk

I wonder if there's a way to define stubs for the macros in the package, 
and use mathjaxr versions only conditional on having it available?  I 
suspect that should be possible, but might require changes in R, not 
just in the individual packages.

As to the workaround in rgl:  since the mathjaxr macros are defined to 
be similar to the existing \eqn and \deqn macros in base R, it was easy 
to switch back to those and I (hopefully temporarily) dropped the 
mathjaxr dependency completely.  For a package that made more extensive 
use of math in the help pages it would be more work.

Duncan Murdoch

On Sat, 23 Jan 2021 04:54:51 -0500

I wonder if there's a way to define stubs for the macros in the
package, and use mathjaxr versions only conditional on having it
available?

I had an idea along the lines of

\Sexpr[results=rd]{if (...) '\\newcommand{\\mjeqn}{...}'}

...but \Sexpr seems to be expanded too late in the Rd processing
pipeline for the \newcommand to have any effect. This also seems to
mean that it's impossible to dynamically load macro definitions
belonging to a different package from a \Sexpr:

% doesn't affect the rest of the document
\Sexpr[results=rd]{
 if (nzchar(f <- system.file('help/macros/mathjax.Rd', 'mathjaxr')))
  readLines(f)
}

An "optional mathjaxr" implementation will probably end up with its own
copy of man/macros/mathjax.Rd (but not the rest of MathJax), with \mjeqn
and friends defined to check whether mathjaxr package is available
before outputting MathJax markup or \eqn.

Loading the rest of the .Rd in the same \Sexpr where \newcommand{} is
evaluated (1) doesn't work because only one Rd section per \Sexpr is
supported and (2) would be a truly horrible hack if it worked.

Best regards,
Ivan