I use a package structure to organize my research projects in R. Of course these projects aren't intended to be built/installed by potential external users who would like to reproduce the results. I was thinking of disabling that functionality just as "extra security".
Since there's nothing documenting the different package options in .Rproj, I've no clue what is the most appropriate. At the moment, I simply use BuildType: None in the .Rproj file. Is there a better approach/recommended way of doing it?
Are you saying you build your packages locally, but don't want someone else to be able to build them if you e.g. share a GitHub repo with them? I'm not sure of how to prevent this unless maybe you prevent committing critical files (DESCRIPTION, NAMESPACE, etc.) in .gitignore or something.. Or maybe organizing your functional code with something like box would work as an alternative to building local packages?
No, I use the base structure of an R package for a research/analysis project. The project is technically a package but is not supposed to be used as a package. I'm not building it myself and don't want people to build it either. The reason of using a package structure is only for convenience. In particular, for the organization of helper functions and their documentation, as well as the handling of the project settings with a DESCRIPTION file.
Although, it's not a big deal if someone actually builds the project, I don't like the idea of people with no knowledge of package development to install something in their R library path without realizing it. For this reason, I wanted to disable that functionality. BuildType: None works but I was wondering if there's something cleaner, more appropriate.
Also, there's a Package field in the DESCRIPTION file. Is it recommended to remove it or change it with something else to make it clear that the project should NOT be used as a package?
Ah, in that case maybe box could work well for you. You can set a module search path in your .Rprofile via the box.path option, and load your modules that way on startup. You can still document all your helper functions with roxygen2. The only difference would be how you call such a function (using $ instead of :: to drive into the namespace), but since you aren't actually installing your package, maybe that isn't just a big deal?
Another option might be to just continue with the package structure, but don't export anything in the NAMESPACE file, and don't declare any dependencies in the DESCRIPTION file. Then if someone did somehow unknowingly install the package, and unknowingly load the package, they wouldn't also unknowingly introduce any conflicts with other namespaces. If you use roxygen2 to document your helper functions, just leave out the @export tag.
I actually tried box before and it was a complete nightmare to use for such a project. box is okay for simple code projects without much inter-dependencies between files (similar to a JS or python project), but that's not useful in R with package projects.
This is very unlikely that a user install and load the library by error (as opposed to just installing it) so this is not my issue. I shouldn't have said that it "is not supposed to be used as a package". It actually is, but not like a regular package with installation and loading with library(). I handle all these steps with pkgload::load_all() to avoid being invasive and write things on users' disk. I do need NAMESPACE to export helper functions for the analysis scripts and manuscript files.
My only concern really is with installing the compendium in users' R lib path, because it isn't supposed to live there.