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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
