Is it possible to generate .Rd files for R functions without manually writing roxygen annotations?
I know one method is to use prompt() but this does not look at arguments or return values.
Can it done through any other command or with RStudio?
Yes, you can just write the files by hand, like most of us did for a long time. See Writing R Extensions for details on the format.
You can source the scripts you want to create a package out of and then use the command
package.skeleton(name = 'MyPackage')
This will create a package based on everything in your current environment so make sure your environment only contains what is necessary to create your package. If you are using devtools (which I recommend you do) then do this outside another folder. This will create a "man" folder that contains .Rd files that serve as the basic template for everything that you sourced that requires documentation. This would save some time as opposed to writing them all by hand.
If you are using devtools, then copy these files into the other 'man' directory in your project.
Related
When developing packages in R all R source files are put in the subdirectory R/, and all compiled code is put in the subdirectory src/.
I would like to add some organisation to files within these folders, rather than have everything dumped at the top level. For example, lets say I'm hypothetically developing a client-server application. Logically, I would like to organise all my client R source files in R/client/ and all my server R source files in R/server/.
Is it possible to organise code in subfolders when developing a package, and if so, how? The Writing R Extensions manual doesn't offer any guidance, nor does R CMD build detect files stored in subfolders under R/.
You can't use subfolders without additional setup (like defining a custom makefile). The best you can do is to use prefixes: client-a.r, client-b.r, server-a.r, server-b.r, etc.
Expanding the comment to Hadley's IMHO incorrect answer:
Look at the Matrix package (written by R Core members) which has five folders below src/, and two of these contain other subfolders. Other example is the Rsymphony packages (co-)written and maintained by an R Core member.
Doing this is not for the faint of heart. R strongly prefers a src/Makevars fragment over a full src/Makefile in order to be able to construct its own Makefile versions for the different subarchitectures. But if you know a little make and are willing to put the effort in, this is entirely doable -- and being done.
That still does not make it recommended though.
I argued with R core team Allow for sub-folders in "package/R/" directory . They seem not really want improve it. So my workflow is as follows.
1) Create an R project same as other packages but allow sub-directories in folder R/ such as
R/mcmc/a.R
R/mcmc/b.R
R/prediction/p1.R
R/predection/p2.R
2) When I need to pack them, I convert all files under R/ as
R/mcmc_a.R
R/mcmc_b.R
R/prediction_p1.R
R/predection_p2.R
...
with my package.flatten() function
3) Then I install the flattened version to R.
I wrote a simple script for Linux to do everything
https://github.com/feng-li/flutils/blob/master/inst/bin/install.HS
Recognizing the thread is a bit old, I just thought I'd throw in my solution to this problem. Note that my issue is similar, but I am only concerned with preserving folder hierarchies in development.
In development, I organize my script files in subfolders to my heart's content, but rather than fight R's flat hierarchy in production, I added my own "compile-time constant", so to speak.
That is, in every file located in a subfolder (not in top-level scripts/), I add the following:
if (!exists("script.debug"))
script.debug = FALSE
Then, I load whatever other dependencies are required as follows:
source.list <- c(
"script_1.R",
"script_2.R",
"script_3.R",
"script_4.R"
)
if (script.debug)
source.list <- paste("./script_subfolder/", source.list, sep="")
lapply(source.list, source)
The default assumption is that the code is in production, (source.debug = FALSE), so when in development, just ensure that source.debug = TRUE and the project's script/ folder is set as the working directory before loading any script files.
Of course, this example's a bit simple - it assumes that all script file dependencies exist in the same folder, but it seems a simple issue to devise a system that would suit more complicated development folder hierarchies.
I have seen that many Julia projects seem to include a file in the test folder called "runtests.jl". Is there something significant about that file name or can I have my testing file called whatever I want?
As noted in the package manager docs, when you run test in the package manager while you have a particular package activated, it will default to looking for a runtests.jl file. From the docs, it does not appear there is a way to override this naming convention so it should be assumed the entry point for you unit tests should be the runtests.jl file.
Is there a way how to call roxygen templates from a different location, other than the current package?
Use Case
I have a lot of packages. Many of them use the same templates for documentation.
If a change is needed in one of the templates, I would like to do it in one place and not have to update multiple packages.
Ideal Solution (in my view at the moment)
I have a package, that I'm using for utility functions used across multiple packages. As a part of that package I would have roxygen templates in man-roxygen folder. And I would like to reference templates from this location in other packages.
Insufficient solutions
Symbolic link to a directory: Not solving the case when some extra templates are needed for individual packages, which shouldn't be in the central repository. (unless I can have more man-roxygen like directories)
Symbolic links to individual files: A hassle of creating such a stuff. And mainly symbolic links are not a solution when SVN is used on multiple platforms including Windows.
Templates inside calling a packageABC::functionXYZ() that returns the text. Cumbersome and it doesn't solve the need to copy files to individual packages.
I have a .tar.gz file of a MeteorJS application. This file was created using this command "meteor build --architecture=os.linux.x86_64 ./". I don't have original source code of this app because the author dev disappeared totally. Now I want to convert the .tar.gz file to a normal MeteorJS source code to add some changes (add third-party packages ...). So is there any way to do this? If not, is there any way to add new third-party packages to the app? Thank you in advance!
I think you probably can reconstruct it.
Looking at one of my projects, under
bundle/programs/server/app/app.js
This file is a concatenation of my source files. You could probably write a script to unpack this into separate files. I don't know if anyone has done it before, but it might be useful to post the tool when you have built it.
When developing packages in R all R source files are put in the subdirectory R/, and all compiled code is put in the subdirectory src/.
I would like to add some organisation to files within these folders, rather than have everything dumped at the top level. For example, lets say I'm hypothetically developing a client-server application. Logically, I would like to organise all my client R source files in R/client/ and all my server R source files in R/server/.
Is it possible to organise code in subfolders when developing a package, and if so, how? The Writing R Extensions manual doesn't offer any guidance, nor does R CMD build detect files stored in subfolders under R/.
You can't use subfolders without additional setup (like defining a custom makefile). The best you can do is to use prefixes: client-a.r, client-b.r, server-a.r, server-b.r, etc.
Expanding the comment to Hadley's IMHO incorrect answer:
Look at the Matrix package (written by R Core members) which has five folders below src/, and two of these contain other subfolders. Other example is the Rsymphony packages (co-)written and maintained by an R Core member.
Doing this is not for the faint of heart. R strongly prefers a src/Makevars fragment over a full src/Makefile in order to be able to construct its own Makefile versions for the different subarchitectures. But if you know a little make and are willing to put the effort in, this is entirely doable -- and being done.
That still does not make it recommended though.
I argued with R core team Allow for sub-folders in "package/R/" directory . They seem not really want improve it. So my workflow is as follows.
1) Create an R project same as other packages but allow sub-directories in folder R/ such as
R/mcmc/a.R
R/mcmc/b.R
R/prediction/p1.R
R/predection/p2.R
2) When I need to pack them, I convert all files under R/ as
R/mcmc_a.R
R/mcmc_b.R
R/prediction_p1.R
R/predection_p2.R
...
with my package.flatten() function
3) Then I install the flattened version to R.
I wrote a simple script for Linux to do everything
https://github.com/feng-li/flutils/blob/master/inst/bin/install.HS
Recognizing the thread is a bit old, I just thought I'd throw in my solution to this problem. Note that my issue is similar, but I am only concerned with preserving folder hierarchies in development.
In development, I organize my script files in subfolders to my heart's content, but rather than fight R's flat hierarchy in production, I added my own "compile-time constant", so to speak.
That is, in every file located in a subfolder (not in top-level scripts/), I add the following:
if (!exists("script.debug"))
script.debug = FALSE
Then, I load whatever other dependencies are required as follows:
source.list <- c(
"script_1.R",
"script_2.R",
"script_3.R",
"script_4.R"
)
if (script.debug)
source.list <- paste("./script_subfolder/", source.list, sep="")
lapply(source.list, source)
The default assumption is that the code is in production, (source.debug = FALSE), so when in development, just ensure that source.debug = TRUE and the project's script/ folder is set as the working directory before loading any script files.
Of course, this example's a bit simple - it assumes that all script file dependencies exist in the same folder, but it seems a simple issue to devise a system that would suit more complicated development folder hierarchies.