I'm trying to get packrat to recognise a package installed from GitHub whose URL has changed.
In previous versions of base R, library(help = "packagename") would reveal documentation that includes details of the remote repository such as the API site, GitHub user, repository name for a package installed from GitHub.
Current versions only show abridged information. Is there another function (or even a package) that I can use to get what I need? The challenge has been piecing together a Google query that can yield the right results
I was able to arrive at the answer with the help of a Redditor:
The information I was looking for is only obtainable via the GitHub API. Thus, I removed the package and reinstalled it from GitHub. On checking it again, as before, with library I can now see the other fields. They include GithubUsername, GithubRepo, RemoteHost, etc.
Related
I'm experimenting with GitHub and I created a little package for my colleagues to use. They install it with the devtools package and install_github() function directly in R. I also have some example data and a R-Markdown file that shows the usage of all functions in the package and can be published via GitHub Pages.
I would like to know what would be the best practice to enable others to use this example data to learn the package.
I can think of two different options:
Host the data in a separate directory which is not part of the installation and tell people to download it manually or use something like the download.file() function from R at the beginning of the example script to download all data that could be packed into a .zip.
Make the data part of the package installation, however this would require the data to be fairly small which is difficult in my particular case (data is 10MB).
Ideally the examples in the R-documentation (.Rd files in the man folder) could also use the same examples as in the markdown file. also in this case, option (2) seems to be favorable.
Could anybody give me some advice what would be the best way to go, sort of the "industry standard" if there is any.
is there a proper way to create NOT by hand a NEWS file for a package in R/RStudio?
Is it ok if i find a way to use the description of commits from the github repo to create this file?
Thank you
You have to interact with the GitHub API using R(REST API v3) to read the commits
You can use R Bindings for the Github v3 API
I'm not sure if it cover all API needed to read the commits (or you can deploy it)
You should take into account that you should standard all changes/bug fixes and version number to get meaningful commits in the NEWS file.
My advice Do it manually (by hand) :)
BTW - anyone who is looking here, look at the fledge package: https://github.com/krlmlr/fledge. It seems to do what you want.
I'm developing a web application that should interact with some R scripts and I would very much like to use openCPU. However, I do not see if there is any way I can do other AJAX requests besides calling the R scripts or fetching their results.
I need to send R script descriptions and other stuff which can change so it has to be done in runtime by requests to server.
If anyone would be kind enough to briefly explain if this is possible, I would be very grateful.
I'm assuming when you say update descriptions that you mean the DESCRIPTION file that acts as the definition of the R package itself. When you change this or the contents of the R script, you will need to publish a new version to Open CPU. A few notes from my experience, which seems similar to yours:
I have had some trouble having scripts running inside of OpenCPU install packages that are in CRAN but not available in the OpenCPU package list. OpenCPU can pull packages in from Github using the install_github function found in the devtools package. You might have to manually install in your R script using install.packages if your script is using an R function that the public OpenCPU doesn't have. This might be helpful if calling library or install.packages by itself doesn't work.
library('devtools')
install.packages("BIOMASS", repos = "https://cran.opencpu.org", method = "libcurl")
library("BIOMASS")
The list of installed packages on the public OpenCPU is here If you are using another package that is available on CRAN, you will need to add it as a dependency in your Imports section in the R package DESCRIPTION file. You can also use namespacing to avoid having to use PACKAGENAME::FUNCTIONNAME in your script.
If you publish to the public OpenCPU, you can only update your package once every 24 hours.
The pipeline I've found helpful is to develop my package, write some test code locally that uses it, and once I'm fairly confident, push it to my github repository. Here I have a webhook setup to publish the new package to the public OpenCPU instance. Depending on how you have your development environment setup, you might publish it manually instead. For example, if you are hosting your own OpenCPU instance, it would make more sense to publish it to your instance instead of the public one.
The relevant section in the OpenCPU API documentation is where it talks about the R Package API. There's also documentation in the server manual about how to install packages if you are hosting your own OpenCPU.
If you happen to be using Meteor, my experience was that it was best to make direct calls to the ReSTful / HTTP API in OpenCPU directly. The Javascript client package didn't work for me in Meteor and the HTTP API works just fine.
In a vein similar to this question: I'm writing a package and am using knitr to write a few documents in inst/doc/. Since I'm using github to host my repo (and I intend to point to people to that repo to get the package), I'm wondering if I should be version controlling my the caches of my various documents.
I ask this question because it's unclear where cache falls in the guidelines provided by this other question (which addresses when certain file types should and shouldn't be in the .gitignore of a repo).
Can anyone shed some light on to how package developers that use knitr and git are handling their caches?
If R CMD check passes without the knitr cache, and I think it would, I wouldn't include them. In fact, I suspect R CMD check would give a note about the cache files being present in the package. I know for LaTeX files, you only want to include the .tex file in the R package and in the version control. The other required files should be automatically generated on install.
I'm creating a custom R package repository and would like to replicate the CRAN archive structure whereby old versions of packages are stored in the src/contrib/Archive/packageName/directory. I'd like to use the install_version function in devtools (source here), but that function is dependent on having a CRAN-like archive structure instead of having all package versions in src/contrib/.
Are there any R package repository management tools that facilitate the creation of this directory structure and other related tasks (e.g. updating the Archive.rds file)?
It would also be nice if the management tools handled the package type logic on the repository side so that I can use the same install.packages() or install_version() code on a Linux server as on my local Mac (i.e. I don't have to use type="both" or type="source" when installing locally on a Mac).
Short answer:
Not really for off-the-shelf use.
Long answer:
There are a couple of tools that one can use to manage their repo, but there isn't a coherent off-the-shelf ecosystem yet.
The CRAN maintainers keep a bevy of scripts here to manage the CRAN repository, but it's unclear how they all work together or which parts are needed to update the package index, run package checks, or manage the directory structure.
The tools::write_PACKAGES function can be used to update the package index, but this needs to be updated each time a package is added, updated, or removed from the repository.
M.eik Michalke has created the roxyPackage package, which has the ability to automatically update a given repository, install it, etc. The developer has also recently added the ability to have the archive structure mimic that of CRAN with the archive_structure function. The downside is the package isn't on CRAN and would probably be better if integrated with devtools. It's also brand new and isn't ready for wide use yet.
Finally, I created a small Ruby script that watches a given repository and updates the package index if any files change. However, this is made to work for my specific organization and will need to be refactored for external use. I can make it more general if anyone is interested in it.