mlibrary lets you use tasks as informal proto-packages. The documentation etc. requirements are much less stringent than for proper packages.# Usual: mlibrary( task=)
mlibrary( ..., character.only=FALSE, logical.return=FALSE, task, pos=lib.pos(), execute.First=TRUE)task will be interpreted as a normal quoted character string..First.lib code. ?Is this working?librarylibrary.mlibrary( task=mytask) loads task mytask as a library. It sets lib.loc based on the disk location of mytask before calling library. If no objects are found in the loaded package after the library call (i.e. if there is no code in the file "R/mytask"), then mlibrary will load the .Rdata file and execute its .First.lib if any (but see below). This binary-loading feature is extremely convenient if you are developing personal proto-libraries and want to avoid the formality of Rsource files, Rd documentation files, and perpetual RCMD INSTALL; it's how I maintain mvbutils, for example. Of course, for CRAN distribution you must do the job properly; formalize.package may help.
To use task XXX as a proto-package loaded via mlibrary(task=XXX), all you need to add to XXX is a DESCRIPTION file in the task directory; none of the usual package subdirectories (not even "R" or "man") need be present.
After mlibrary( task=mytask), you can cd(mytask) to bring mytask into the active workspace (top of the search path); see cd. Note that mlibrary calls .First.lib, while cd calls .First.task, and you probably don't want both in a single task.
execute.First=FALSE is useful for debugging; if there is a problem in .First.lib, normal library will just refuse to load the package.
mlibrary without a task argument will duplicate library. In particular, .execute.First=FALSE will have no effect.cd, formalize.package