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.
Related
I'm barely new to CI/CD piplines with GIT and hope that my questions is related to that functionality. I want to achieve the following:
Whenever a new commit (or tag) of a specific package in our companies local git server is created, I want to execute a shell script on a remote server. This shell script should download this new version of the package and install it into the global R-Installation, making it available for different processes that use this R environment. So far this is more like a manual step but I really would like to automate the process. Is this possible?
Thanks!
my company has hosted a private GitLab server, which I'm accessing via VPN from my laptop.
I am currently working on some technical reports (repository 1) using RMarkdown and decided to create a template package for my RMarkdown HTML template files in a separate, private repository (repository 2).
My goal is to install the package from repository 2 from within the project of repository 1 in RStudio. I tried using remotes::install_gitlab for this purpose, however I get an error message, I do not really understand.
My guess is, that this is mostly, because it's the first time I got in touch with GitLab, so maybe there is a very obvious solution - I simply couldn't find it yet.
What I'm trying to do
remotes::install_gitlab(repo = "USERNAME/REPOSITORY", host = "https://HOST_IP")
#> Error: Failed to install 'unknown package' from GitLab:
#> cannot open URL 'https://HOST_IP/api/v4/projects/USERNAME%2FREPOSITORY/repository/files/DESCRIPTION/raw?ref=HEAD'
First of all, the URL remotes is trying to open really does not exist, but I can access the repo via https://HOST_IP/USERNAME/REPOSITORY without any problems. I understand, that it tries to use GitLab's API to install the repository, however I don't understand what's going wrong here. Is there a problem with my authentication? Do I need to create some kind of access token I'm not aware of?
Thank you all for your input!
We are evaluating the migration from our current client/server application to .NET Core. The 3.0 release added the support for WinForms we need for our client, but ClickOnce will not be supported.
Our solution is installed on-premise and we need to include settings (among others) like the address to the application server. We create dynamically ClickOnce packages that can be used to install and update the clients and include the settings. This is working like a charm today. The users install the client using the ClickOnce package and every time we update the software we regenerate these packages at the customer's site and they get automatically the new version with the right settings.
We are looking at MSIX as an alternative, but we have got a question:
- Is it possible to add some external settings files to the MSIX package that will be used (deployed) when installing?
The package for the software itself could be statically generated, but how could we distribute the settings to the clients on first install / update?
MSIX has support for modification packages. This is close to what you want, the customization is done with a separate package installed after you install the main MSIX package of your app.
It cannot be installed at the same time as your main app. The OS checks if the main app is installed when you try to install the modification package and it will reject its installation if the main is not found on the machine.
The modification package is a standalone package, installed in a separate location. Check the link I included, there is a screenshot of a PS window where you can see the install path for the main package and the modification are different.
At runtime (when the user launches the app) the OS knows these two packages are connected and merges their virtual files and registry system, so the app "believes" all the resources are in one package.
This means you can update the main app and the modification package separately, and deploy them as you wish.
And if we update the modification package itself (without touching the main), will it be re-installed to all the clients that used it?
How do you deploy the updates? Do you want to use an auto-updater tool over the internet? Or ar these users managed inside an internal company network and get all the app updates from tools like SCCM?
The modification packages were designed mostly for IT departments to use them, and this is what I understood you would need too.
A modification package is deployed via SCCM or other tools just like the main package, there are no differences.
For ISVs I believe optional packages are a better solution.
I just saw a package that, in order to run properly, asks you to put something in the public section of settings.json. That made me wonder if the rest of the information there (sometimes sensible, like AWS keys) is accessible as well.
So, should I be worried about this or does Meteor hides this information from packages?
Any package you install from any package manager including NPM, Ruby Gems, and the Meteor package server can run arbitrary code on your computer as your user, including using the fs module to read and write files, accessing the network to send and receive data, etc.
In fact, you place the same trust in the developer whenever you install an application from the internet - almost any application on your computer could read your settings.json file, for example Dropbox, Chrome, etc.
Therefore, there is no way to completely secure the settings.json file from package code. The only way to be sure that packages are safe is to use only community-approved packages or read the source code of the packages you are using.
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.