[rkward-devel] R2HTML orphaned on CRAN

[Milan Bouchet-Valat]

Le mercredi 20 août 2014 à 17:23 +0200, Thomas Friedrichsmeier a écrit :
> Hi!
> 
> On Wednesday 20 August 2014 14:56:02 meik michalke wrote:
> > Am Mittwoch, 20. August 2014, 13:57:06 schrieb Milan Bouchet-Valat:
> > >  If nobody steps in to take up
> > > 
> > > maintainership, it will eventually be archived. As RKWard uses R2HTML
> > > for output, it would be quite a bad situation.
> > 
> > indeed.
> > 
> > > Would you be interested in working at fixing the few R CMD check WARNINGs
> > > and NOTEs in order to update the package?
> > 
> > i sure don't have time to dig into the package to feel comfortable enough to
> > make changes.
> 
> Well, yeah, we don't seem to be swimming in developer ressources, ATM.
> 
> > what are the options? evaluate which functionalitiy RKWard uses exactly, and
> > try to replace R2HTML with maintained alternatives (if there is any)? two
> > things come to my mind:
> > 
> >  print(xtable(), format="HTML")
> > 
> > and extending XiMpLe to make generating HTML easy enough to become
> > independent from other packages? here's some stuff i've been toying around
> > for some other project:
> 
> That may not be the part that's actually difficult. BTW, we already create a 
> custom HTML header in the first place. See rk.set.output.html.file().
> 
> The really nice thing about R2HTML is that you can simply do
>    HTML (x)
> (or rk.print (x)) and expect a reasonable result for most common classes of 
> objects. I do not think we actually use too many different classes in existing 
> plugins (some tables, lm-, and htest-objects, as far as I am aware), but so 
> far we can simply hint plugin authors to use rk.print(results) as a first, and 
> often sufficient way to present results.
> 
> Should R2HTML really go away, copying the bits we actually use, should not be 
> too hard. Alternatively, for most purposes,
>    rk.print.literal (capture.output (x))
> or
>    rk.print.literal (capture.output (summary (results)))
> would do the trick reasonably well. (And in fact, for some things, it may also 
> be preferrable).
> 
> One thing that could really mean trouble for us, is if R2HTML goes away, 
> before we are prepared for it. So I guess we need to decide (before 0.6.2), 
> whether
> 
> a) We rely on R2HTML to continue to be available on CRAN, because it's still 
> pretty popular, and somebody will certainly step forward.
> b) We rely on R2HTML to continue to be available on CRAN, because we take care 
> of ensuring that ourselves.
> c) We modify rk.print() to be functional without R2HTML, so disappearance of 
> R2HTML won't be catastrophic to RKWard.
> 
> Thoughts?
We can probably all copy the bits we need in our packages, but this is
going to require some work anyway, and this time could be better spent
by pooling resources of people who currently rely on R2HTML. All R users
would benefit from it.

I don't think fixing it will require deep understanding of the package:
looking at the 3 NOTEs, 2 may be fixed with really trivial changes, and
only one (assignment in the global environment) appears really serious:
http://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/R2HTML-00check.html

If fixing all of R2HTML would take too much time, we could as well
remove the offending functions, as it's always better for users than not
being able to install the package from CRAN at all.

If you are OK, I can volunteer for fixing the assignment in the global
environment issue, and you would fix the two easier NOTEs. Then I would
take care of maintaining the package. Deal? ;-)


Regards