Create documentation paradigm for modules #125
Comments
I started with using roxygenize2 ideas, but it may need more thought. Maybe it is fine. See commit a76db0e |
Module metadata at top of the module's
Module distributionHosted in a separate GitHub repo ( Module data will NOT be included/hosted in our repo. They must be accessible elsewhere, and code/instructions for this step should be included in the module documentation. Modules can be contributed to our repo via pull requests, which also provides easier quality assurance on our part with respect to contributed modules' structure and documentation. Module directory structure:
|
Still need to change the simInit function, so that path argument is the base folder for modules, and modules are subfolders within that. |
other than updating the sample module docs as noted in 3b1b0e7, I think this can be closed. |
ISSUE: still grappling with environments `source()` evaluates the code in the env given by `local` - `local=TRUE` means parent frame `eval()` evaluates the code in the given env but it’s not persistent???
part of #125 and #126 - use two separate files for module metadata & code - `metadata.R` sourced to local env. - `moduleName.R` code sourced to `.GlobalEnv` - update module template and sample modules to reflect this - remove function `prevArgs` and reintegrate code in `.objectNames` - separate dependency classes and methods into two R files
This is the general issue for #21 #22 #23 #24 #25
The text was updated successfully, but these errors were encountered: