[rkward-devel] a new approach to external plugins

meik michalke Meik.Michalke at uni-duesseldorf.de
Wed Aug 10 14:39:52 UTC 2011


hi,

Am Montag, 8. August 2011, 17:41:26 schrieb meik michalke:
> 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.

to clear this bit up, here's what i'd propose as the standard plugin archive 
hierarchy. first, this is the current state, as described in the 
documentation:

<old>
 plugin_name/
   plugins/
     plugin_name.xml
     plugin_name.js
     plugin_name.rkh
     ...
   tests/
      sometestsuitename/
         RKTestStandards.sometest.rkcommands.R
         RKTestStandards.sometest.rkout
         ...
      testsuite.R
   plugin_name.pluginmap
   ChangeLog
   README
   AUTHORS
   LICENSE
   ...
</old>

it's only minor changes to turn this into an R package that would install 
without errors:

<new>
 plugin_name/
   inst/
     rkward/
       plugins/
         plugin_name.xml
         plugin_name.js
         plugin_name.rkh
         ...
       tests/
          sometestsuitename/
             RKTestStandards.sometest.rkcommands.R
             RKTestStandards.sometest.rkout
             ...
          testsuite.R
       plugin_name.pluginmap
       ChangeLog
       AUTHORS
       DESCRIPTION.RKWard
       LICENSE
       README
       ...
 DESCRIPTION
</new>

in summary, there's only two differences:
 - a valid DESCRIPTION needs to be added (which is very easy, using 
   write.dcf(), which i just discovered for myself... see below)
 - all the previous contets move unchanged as they are from the root
   directory to "inst/rkward/"

(- regarding the added "DESCRIPTION.RKWard", see below, just an idea)

when installed, everything in "inst" is copied to the root of the installation 
directory, i.e. a package "myFoo" containing "myFoo/inst/rkward/...", 
installed with install.package("myFoo"), will end up like 
"$LibPath/myFoo/rkward/...".

and looking at read.dcf(), would you think it might be easier to move the 
<about></about> section from the .pluginmap to a DESRIPTION-like format? in 
contrast to the XML coded info, it would at least be human readable, directly 
accessible from R, and much easier to produce (e.g. by a script), too:

  plugin.descr <- data.frame(
	Plugin="myFoo", # instead of "Package"
	Title="Evaluate bar.",
	Version="0.1-2",
	Date=format(Sys.time(), "%Y-%m-%d"),
	Author="John Doe",
	Maintainer="Jane Doe <jd at example.com>",
	Depends="R (>= 2.10), RKWard (>= 0.5.3)",
	Category="Foo Bar", # optional
	License="GPL (>= 3)",
	URL="http://myFoo.example.com")

  write.dcf(plugin.descr, file="DESCRIPTION.RKWard")

  read.dcf("DESCRIPTION.RKWard")

to access information from an installed package:

  read.dcf(system.file(file.path("rkward", "DESCRIPTION.RKWard"),
    package="myFoo"))

regarding support for several authors: duplicate entries are valid, so you 
could append multiple "Author" lines. as long as nothing if that section is 
evaluated as of now anyway, it wouldn't break anything, would it? are there 
any reasons to keep it in XML, though?


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/20110810/b86dcc74/attachment.sig>


More information about the Rkward-devel mailing list