I am tweaking an R package for which I have the source; the relevant code is in R not C. I'm making changes to the package code. What is the best workflow for doing this? I recall the advice used to be to remove the NAMESPACE during development, but I don't think this is possible anymore. For simplicity, suppose I have an outer level function f defined in f.R and an innder g in g.R defined in the package. My understanding is that if I modify g.R and load it (e.g., C-c C-l in ESS) this will have no effect on the code the f calls, since the latter is in a namespace. If I modify f.R and import it, I'm not sure if it can find g at all if it has not been exported. Web searches and reviewing the R Extensions manual have turned up information on how to trace into functions in namesapces, but not on the larger development cycle. Thanks. Ross
On 04/02/2013 12:59 PM, Ross Boylan wrote:> I am tweaking an R package for which I have the source; the relevant code > is in R not C. I'm making changes to the package code. > > What is the best workflow for doing this? I recall the advice used to be > to remove the NAMESPACE during development, but I don't think this is > possible anymore. > > For simplicity, suppose I have an outer level function f defined in f.R > and an innder g in g.R defined in the package. > > My understanding is that if I modify g.R and load it (e.g., C-c C-l in > ESS) this will have no effect on the code the f calls, since the latter is > in a namespace. > > If I modify f.R and import it, I'm not sure if it can find g at all if it > has not been exported. > > Web searches and reviewing the R Extensions manual have turned up > information on how to trace into functions in namesapces, but not on the > larger development cycle.I think the best workflow is to do the edits outside of R, and re-install the package to test. It is possible to do edits to a loaded package, using the assignInNamespace() function, but I don't think there's a simple workflow that doesn't end up with multiple copies of functions, and possible confusion over which version - is in the source, so will be saved - is in the global env, so will be executed by a user at the top level - is in the namespace, so will be executed by calls from other functions in the namespace. This is something that could probably be handled well by a smart editor. I don't know if any of the existing IDEs do it. Duncan Murdoch
On Mon, Feb 4, 2013 at 6:23 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:> On 04/02/2013 12:59 PM, Ross Boylan wrote: >> I am tweaking an R package for which I have the source; the relevant code >> is in R not C. I'm making changes to the package code. >> >> What is the best workflow for doing this? I recall the advice used to be >> to remove the NAMESPACE during development, but I don't think this is >> possible anymore. >> >> For simplicity, suppose I have an outer level function f defined in f.R >> and an innder g in g.R defined in the package. >> >> My understanding is that if I modify g.R and load it (e.g., C-c C-l in >> ESS) this will have no effect on the code the f calls, since the latter is >> in a namespace. >> >> If I modify f.R and import it, I'm not sure if it can find g at all if it >> has not been exported. >> >> Web searches and reviewing the R Extensions manual have turned up >> information on how to trace into functions in namesapces, but not on the >> larger development cycle. > > I think the best workflow is to do the edits outside of R, and > re-install the package to test.Isn't the best[1] workflow to use devtools? Edit the code in-place, do load_all("packagefolder") and devtools' magic does the rest? Without polluting the workspace. Since I started doing that I hardly ever C-c C-l into ESS any more. All my functions are in packages, sometimes the package is just created ad-hoc with devtools' create("packagefolder") function. Lightweight, yet fully-functional packages. Dream. Barry [1] for some value of "best"