My institution recently installed GitLab for us. I've figured out how to install R packages from the GitLab server using devtools::install_git and it works as long as the project is public.
#* When modeltable project has Public status
devtools::install_git('https://mini-me2.lerner.ccf.org/nutterb/modeltable.git')
However, if I have a package that is listed as either "Internal" or "Private," I can't install the package without some form of authentication. As of yet, I haven't figured out how to pass authentication via the URL. Does anyone have experience with downloading packages from GitLab?
#* After changing the 'modeltable' project to Private status
devtools::install_git('https://mini-me2.lerner.ccf.org/nutterb/modeltable.git')
Preparing installation of modeltable using the Git-URL: https://mini-me2.lerner.ccf.org/nutterb/modeltable.git
'/usr/bin/git'clone --depth 1 --no-hardlinks https://mini-me2.lerner.ccf.org/nutterb/modeltable.git /tmp/Rtmp5aj1cU/file24493dc03a32
Error: There seems to be a problem retrieving this Git-URL.
I'd highly recommend going the SSH route, and the below works for that. I found making the leap to SSH was easy, especially with R and RStudio. I'm using Windows in the below example. Edits from code I use in practice are in all caps.
creds = git2r::cred_ssh_key("C:\\Users\\MYSELF\\.ssh\\id_rsa.pub",
"C:\\Users\\MYSELF\\.ssh\\id_rsa")
devtools::install_git("git#gitlab.WORKDOMAIN.com:GITLABGROUP/PACKAGE.git",
credentials = creds)
Two quick additional comments:
git2r is imported with devtools, you shouldn't need to install it separately.
Also I don't think this should need mentioning, but passwords in plaintext in your script is a very bad idea.
You could try a combination of the devtools and getPass packages.
https://github.com/wrathematics/getPass
devtools::install_git(
"https://gitlab.com/foo/bar.git",
credentials = git2r::cred_user_pass("uname", getPass::getPass())
)
Where uname is your Gitlab user name.
Per Ciro's comment, authenticating using
https://user:password#domain.com/user/repo.git
does the trick. So the complete call would be
devtools::install_git('https://user:password#mini-me2.lerner.ccf.org/nutterb/modeltable.git')
Please note that there may be security concerns with passing the user name and password this way. I'm not completely educated on those concerns. This works well enough for my purposes because I am authenticated on my company's network to even see the GitLab server.
Related
I am trying to update a R app on the OpenCPU public server (https://cloud.opencpu.org/).
With the new 2.2.0 OpenCPU release, all previous user payloads have apparently been wiped out (including mine).
The CI webhook is still up and running though. However, it systematically rejects the R package that I am trying to push through. Note that my app/CI used to work very well with previous OpenCPU versions. Error given is "server timeout".
Could not find any relevant info for this in the docs (OpenCPU help)
Is the public CI flow still available? Are other devs experiencing the same issue?
I can now confirm that the OpenCPU server is actually fully operational.
My web-app is now fixed. Works well. The problem was from my side.
Sharing here my findings, so it can be useful for others:
My custom R package was trying to import too many external packages. I trimmed down the imports list to the strict minimum.
I set my custom package lazyload flag to false
The CI webhook now processes any new push to the Github branch and the corresponding package gets rebuilt smoothly server side.
Here is a example situation: I wish to test if a new user of my R package will be able to install. If it will demand any additional configuration that I have in my developer environment and the user do not have.
I would like to see possibilities. I have already tried Docker and Virtual Machines. But I guess that exists easier ways to accomplish this!
Edit:
What I want is possible to do in Virtual Machines/Docker!
I made a brand-new system to check what errors can I get when installing the package in this new environment.
What I really want here is to know how to do a new configuration of a new environment in my own PC, and not in a virtual machine like system.
if(!require(somepackage)){
install.packages("somepackage")
library(somepackage)
}
Maybe this is some of your solution in the packages question
Link of the info:
Elegant way to check for missing packages and install them?
My enterprise has a Git repository. To make changes, I have to make changes in my forked repository and then make a pull request.
I primarily use RStudio, so I have enabled its integration with Git. I can make changes to my forked repository and then push, pull, sync, etc. The problem is that I still have an additional step of logging into GitHub and making a pull request for my forked repository. Is there a way of doing this from RStudio?
I too use RStudio for R development and I do not believe there is a way to do this. The reason is because this is more than just adding code to a branch, you're requesting a management feature to take place which is pulling part of your code into another branch of the code base. RStudio appears to be limited to pulling, syncing and committing. Likely you need to use a separate, more full featured GitHub client.
This could be done via the GitHub API, which could be executed from an R package using the httr or curl package, after which such a package could have an addin for RStudio, which would let you check everything using a nice Shiny app!
Now we only need to look for someone who wants to develop this… Can’t seem to find it (Jan 2022).
Question:
I am developing an R package. I have not yet submitted to CRAN (and it's not ready to at any rate). I want to send the package to friend for some preliminary testing (he's not a builder) and I just want to see if he can use a few features.
On my Mac version of RStudio, I can generate binaries easily. It creates a file called "iatgen_1.0.tgz"
Can my friend use that to install my early build on his windows machine? Or do I need to do something to that file to make it usable for a windows user. Let's assume I have NO access to a windows machine. What can I do from my mac to make this package usable by windows users?
I am posting my comment as an (extended) answer because I think it will help you. When I built my package, I did not have access to Windows either and was suffering from the same issue. I discovered the the Windows build service offered at http://win-builder.r-project.org/ and it worked great. You'll need to do a few things before you send it in, and this is all explained on the site.
First, build your source package with R CMD build. Next, check the package with R CMD check. If this succeeds, follow the rest of the instructions on the site and if all goes well they will send you a link to the temporary directory on their server where you can download the Windows build. If all does not go well, Mr. Ligges will send you an email with the detailed issues so you can fix them and try again.
Like I said, the service worked very well for me. The response was prompt and there were absolutely no problems.
The default R library, .Library, is normally not writeable under Windows.
You need to run R as Administrator. For new packages you can set and use a personal library, but this doesn't work when updating packages in the base setup (e.g. by update.packages()).
If you forget (or don't know you need) to run as Administrator, you get duplicate versions of the same packages, messing the installation.
I think one solution could be copying all packages to a personal library and disabling the default one. I know how to add a new library path to R, i.e. .libPaths ("my/path"), but how to remove the default library from .libPaths ()?
Update for non-Windows users
Some clarifications might help mostly non-Windows R users to understand the mentioned problem.
In Windows "Log on as Administrator" (or better as a user belonging to administrators' group) and "Run as Administrator" are quite different things.
In the former case you just give your credentials at logon, much like in Linux; in the latter you are already logged as a "superuser", but in order to carry out a potentially dangerous action, you have to ask an ad hoc permission to Windows (proving that it's you and not a malware acting).
That's said, programs (and developers), before accessing known Windows' protected objects (i.e. C:\Program Files folder), ask permission to the user to avoid being blocked by the OS.
Even when they don't ask (because they assume the knowledgeable user should give this permission in advance), failure to access is normally reported like "Permission denied to access to folder etc.".
As for R version 3.0.2, update.packages() involves one of the situations, where an elevated permission request should be triggered, because this might involve writing to protected program folders. Unfortunately R doesn't ask and cannot update the directory with old packages.
What about the second safe net: user notifications? While install.packages() gives messages like:
stop ... "'lib' element %s is not a writable directory" ...
and you get the idea of a permission problem, with others functions, such as update.packages(), you get:
warning ... "package '%s' in library '%s' will not be updated"
whose causes can be everything.
Can this scenario be even worse? Yes. Besides not asking for permission to write to "Program Folders", besides not issuing a notification of the permission error, update.packages(), when unable to update packages in protected folders, actually installs them to the personal user folder, but without notifying this. This is similar to what install.packages() does, except that the latter notifies and asks permission to do this.
So you end up with two versions of the same packages in different folders! Your calculations will be therefore dependent on library priorities.
Can this scenario be even worse? Yes. You are clever (or Google) enough to understand that you need to "Run as Administrator", when you want to update packages. You restart R as Administrator and hope this will fix everything. Not at all. R sees the updated packages in the personal library and does not act. So you remain with two versions of the same packages.
To solve this you have to detect duplicate packages and remove them manually, then restart R as administrator and update again (or write a script to do this).
Clearly the solution would be R conforming to Windows apps expected behaviour, or at least do nothing when prevented to act (instead of taking non-notified decisions).
In the meantime I think that totally disabling the default library (located in a protected area) would be a temporary workaround.
A final note. Packages and package updating are crucial for using R, so my humble opinion is that the topic should deserve specific careful attention even for less GNU-blessed systems like Windows.
One solution is to change R_LIBS environment variable. You can see for example this question.
But If you don't have admin rights, you can specify location when you load the package:
library(my_package, lib.loc="my/path")