[rkward-devel] a new approach to external plugins

[meik michalke]

hi,

Am Montag, 8. August 2011, 10:49:52 schrieb Thomas Friedrichsmeier:
> On Wednesday 03 August 2011, meik michalke wrote:
> > i mean, why not simply have R's packaging system
> > manage RKWard's add-ons as well?
> 
> it would probably make sense to add support for this, indeed. However, the
> current mechanism should certainly stay: Plugins are not necessarily tied
> to a specific R package.

true, they aren't. but i think that shouldn't matter much, which i would like 
to explain some more:

you can easily create an "R package" that has no real package payload (like i 
said, a valid DESCRIPTION file is roughly it). so we'd just have to alter the 
specification of external plugins a little, so that each external RKWard 
plugin can also be seen as a valid R package. no-one actually has to 
understand that, as long as they just put the plugin stuff in a directory 
called 'inst'...

which wouldn't do much harm now, as there seem to be just my two packages yet. 
it would have several advantages:
- only one, not two ways of packaging and providing external plugins, and one 
transparent location where they're stored, which should be easier to maintain, 
especially if something is to be changed
- plugins could profit from the dependency management of R packages, which in 
turn wouldn't have to be re-invented for the plugin system
- plugins could be kept up-to-date by the same tools R uses for its packages 
anyway (and the existing RKWard package dialog)
- easy bundling of a plugin with helpful R functions
- plugins could be offered in the form of an R repository

even if the GHNS frontend would remain as it is, it could as well be filled 
with these packages. as an alternative, the R package management dialog in 
RKWard could also be used for this task. but it should be clear somehow which 
is an ordinary R package and which comes with a plugin; perhaps as a 
sort/filter function in the "install" tab; maybe scan 
.rk.cached.available.packages() for "Enhaces: rkward"?

> Let's think about the details a bit: I'm sceptical that a Makefile based
> approach will work reliably across systems / platforms. Of course, if you
> can make it work, go proove me wrong.

i admit it was just a shot in the dark. i didn't read into the details too 
much yet, and i haven't tried anything.

> So then the follow-up question is: When should rkward scan for new packages
> with pluginmaps? I think there are three options:
> 1) Whenever a new package is installed / updated using RKWard's package
> management UI, scan that package for new / updated .pluginmaps.
> 2) Option 1 and additionally once at the start of each session (to cover
> packages that were installed outside of RKWard).
> 3) Every time a package is loaded, scan only that package for a pluginmap.

how about combining 1) and 3)? wouldn't cause much overhead and be obvious 
enough.

> a) If the fact that a .pluginmap is supplied could be listed in the
> DESCRIPTION-file somewhere, the scanning-mechanism could simply rely on
> installed.packages, too, thus sharing the cost. I'm not sure, whether
> custom fields are allowed in the DESCRIPTION file, though, or whether
> "Enhances: rkward" would be a "legal" representation.

i'd say that it would be valid:

"Finally, the ‘Enhances’ field lists packages “enhanced” by the package at 
hand, e.g., by providing methods for classes from these packages."
 o http://cran.r-project.org/doc/manuals/R-exts.html#The-DESCRIPTION-file

i've already added "Enhances: rkward" to the DESCRIPTIONS of my two packages 
(but they're not in the repo, i'll upload them later this evening).

e.g., they can now be filtered rather fast out by:

  subset(as.data.frame(installed.packages()), grepl("rkward", Enhances),
    select=Package:LibPath)

> b) If you start from scratch, instead: If your scanning mechansim would
> return a list of all installed package-names as a side-effect, that info
> could be used to speed up the start-up.

hm, i don't think i am able to speed up installed.packages() ;-)


viele grüße :: m.eik

-- 
  dipl. psych. meik michalke
  abt. f"ur diagnostik und differentielle psychologie
  institut f"ur experimentelle psychologie
  heinrich-heine-universit"at d"usseldorf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20110808/76e8f3a1/attachment.sig>