If "tee" eventually moves to Rtools, then this won't be necessary. You can get one version from Coreutils in GnuWin32 make sure this is on your PATH, but probably after the Rtools folders required by the R build process, to avoid conflicts between the other Coreutils versions and those in Rtools (I don't know what I'm talking about here, obviously I'm just describing what I've done, which seems to work). (Turn off "buffered output" in RGui to see it as it's happening.) This requires the existence of the "tee" shell redirection facility, which is built-in to Linux and presumably Macs, but not to Windows. It will have several attributes attached, most usefully "output" which duplicates what's printed while the functions are running. Ideally, the "status code" of the corresponding RCMD operation: 0 for success or some other integer if not. Name-value pairs of system environment variables (not used for now) Value you have to do so yourself see *Details* Arguments if you need to set env vars eg PATH for R CMD to work, then. Install.pkg( pkg, character.only=FALSE, lib=.libPaths(), flags=character(0),īuild.pkg( pkg, character.only=FALSE, flags=character(0), =TRUE)ī( pkg, character.only=FALSE, flags=character(0),Ĭ=TRUE, multiarch=NA, preclean=TRUE)Ĭheck.pkg( pkg, character.only=FALSE, build.flags=character(0),Ĭ( pkg, character.only=FALSE) looks through all "Rx.y" folders (where built packages live) and deletes the least-recent ".tar.gz" and ".zip" files in each (regardless of which built package versions are in the other "Rx.y" folders). There are also two minor housekeeping functions: to tidy up detritus, and which does absolutely nothing (yet). INSTALLPKG ALLOWUNTRUSTED FULLSee "Folders and R versions" in for full details. If no such folder exists, then 'build.pkg/" will create one from the running R version you can also create such a folder manually, as a kind of "checkpoint", when you want to make your package dependent on a specific R version. functions work in the highest-versioned "Rx.y" folder that is not newer than the running R version. Normally you shouldn't have to mess around with the folder structure, but you will still need to know where built packages are put so that you can send them to other people. Source packages and built packages go into various folders, depending on various things. After that very first installation, you'd probably only need to call install.pkg if (when.) new versions of R entail re-installation of packages, and build.pkg//check.pkg when you want to give your package to others, either directly or via CRAN etc. The mvbutils approach deliberately makes re-installation a rare event, and one call to install.pkg might suffice for the entire life of a simple package. They are designed to be used on packages created from tasks via mvbutils package, specifically pre.install (though they can be used for "home-made" packages). These are convenient wrappers for R's package creation and installation tools. Install.pkg: Package building, distributing, and checking Description
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |