Loads a module bar that’s defined inside the package foo.
Open questions
What happens when users say library(foo) (or indeed loadNamespace("foo"))? Is there some boilerplate code inside the package that (a) forbids this, (b) does nothing or (c) provides an alternative way of interacting with the modules nested under ‘foo’?
How does this work with the existing R package infrastructure (testing, checking, vignette building, static analysis/‘codetools’)?
(Why) is this desirable? (In particular: people like packages because of the convenience afforded by the infrastructure around packages, but what part of this are we giving up by having the code inside the package hidden away in submodules?)
How ergonomic is this? — Both for the users of the package as well as the developers of it?
Requirements
[ ] R packages don’t allow nested code, so the actual implementation needs to go under inst
[ ] Something (box?) needs to provide utilities to generate the package skeleton infrastructure
klmr
commented
2 years ago
Please describe your feature request
Can the following ever work?
Loads a module
barthat’s defined inside the packagefoo.Open questions
What happens when users say
library(foo)(or indeedloadNamespace("foo"))? Is there some boilerplate code inside the package that (a) forbids this, (b) does nothing or (c) provides an alternative way of interacting with the modules nested under ‘foo’?How does this work with the existing R package infrastructure (testing, checking, vignette building, static analysis/‘codetools’)?
(Why) is this desirable? (In particular: people like packages because of the convenience afforded by the infrastructure around packages, but what part of this are we giving up by having the code inside the package hidden away in submodules?)
How ergonomic is this? — Both for the users of the package as well as the developers of it?
Requirements
inst