I am having some sort of communication issue with my RStudio project and GitHub, potentially related to updating R and RStudio.
I recently updated my R to version 4.0.3 on my windows machine:
R version 4.0.3 (2020-10-10); Platform: x86_64-w64-mingw32/x64 (64-bit)
I also updated my RStudio to Version 1.3.1093, and finally, as a result of the issues below, I updated my git version to 2.30.0.windows.1
I have two existing R Packages hosted on GitHub, and recently created a third. To create my new Repo and link it to my local project I followed the instructions on:
https://aberdeenstudygroup.github.io/studyGroup/lessons/SG-T1-GitHubVersionControl/VersionControl/
I have interacted with GitHub to update my current packages, but it's been years since I created a new repository. It wasn't easy but eventually everything seemed to be working properly. I made some edits, performed a commit, went to push (using the shell or RStudio's GUI) and got this error:
To github.com:user/repo.git
! [rejected] HEAD -> main (non-fast-forward)
error: failed to push some refs to 'github.com:user/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
I am the only person using this repo, and when I perform a pull, I'm told everything is up to date. I also found a post suggesting I first fetch, then rebase (Git push rejected "non-fast-forward"). When I tried these steps I got an error:
$ git rebase tmp
error: could not apply 4fc4d3e... Conflict test
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 4fc4d3e... Conflict test
CONFLICT (add/add): Merge conflict in R/conflict test.R
Auto-merging R/conflict test.R
How do I have a conflict? How can my local copy be behind if I am the only one working on this project?
To work around this I've started performing commits, then forcing the push via git push -f origin main. Since I am the only person who will ever work on this project, perhaps this is safe; however, it's obviously not recommended and shouldn't be needed.
Also, I went back to my previous packages and performed some test commits. Sure enough, I now have this same error when I try to push new commits to GitHub for packages that were communicating perfectly previously.
I have spent some time trying to figure this out, but my efforts are limited to trying to create the repo and local package in different ways and connecting them with SSH vs URL, etc. I'm not well versed in GitHub; once my previous projects were set up I just used the same protocol to commit and push (again, I am the only user editing any of these packages). My guess is that somehow my updates to R, RStudio, or git seem to have created some sort of communication issue that I can't figure out.
I more or less follow this guideline:
Run installr::updater() from ../R-4.0.0/bin/x64/Rgui.exe (as suggested if you run it from RStudio)
Update all packages (check the "update all packages" box from installr::updater())
Change Windows system environment variable R_LIBS in my case to ..\R\R-4.0.x\library.
If I want to switch the R vesion from RStudio, I need to
Set Tools -> Global Options -> General -> R version AND
change R_LIBS to the correct place. (If you forget this, .libPaths() has more than one entry.)
So my questions are:
Is that process correct? Do I miss anything?
What about changing Rtools when switching between major R-versions, see e.g. here?
It seems installr::updater() does not update the packages, although I check the "update all packages" box. (We observed that behaviour on two different laptops.)
It seems, .Rprofile, .Renviron, and Rprofile.site play a crucial role, see RStudio. Last time, everything worked fine, .Rprofile and .Renviron were empty and I had to add the line .libPaths("path2/R-4.0.4/library") to Rprofile.site. It seems you can use usethis::edit_r_profile() to finde those files.
Background: I had this question which was reproducible before I upgraded R to 4.0.2, but I realized, that after switching between
R 3.5.1, 4.0.0 and 4.0.2 back and forth for testing it is not reproducible anymore.
Thus I think, that my update-process was error-prone.
Two years later, I more or less follow this process with success:
(Windows: Make sure R and RStudio are located C:\. Otherwise you run in trouble with .libPaths()!)
Run installr::updater() from C:/R-4.x.y/bin/x64/Rgui.exe (as suggested if you run it from RStudio)
Update Windows PATH variables
Update all packages (check the "update all packages" box from installr::updater())
Keep packages at the old R-version if you like
If you follow this process, R_LIBS, .Rprofile, and .Renviron should have no impact (it seems).
I just setup version control in RStudio (letting RStudio add a Git repository to my existing RStudio project). However, when I use RStudio's Tools->Version Control->History functionality, the timestamps listed for my commits are 4 hours ahead of what they should be. But if I run git log from the terminal the correct timestamps are shown, so it doesn't seem to be an issue with Git. Any idea what might be causing this? I'm using the newest version of RStudio on a Mac.
I am using R 2.13.0 with windows 7, after giving my user full privileges to the R folder (as described here).
This allows me to install new packages just fine.
However, when using update.packages(), to update existing packages, I keep getting the following error (for example, when updating the MASS package):
package 'MASS' successfully unpacked and MD5 sums checked
Warning: unable to move temporary installation
'C:\Program
Files\R\R-2.13.0\library\file6cae3bcf\MASS'
to 'C:\Program
Files\R\R-2.13.0\library\MASS'
Any suggestions on how to fix this?
p.s: Running R as an administrator or shifting the library location out of Program Files is not a solution (it's a hack - but I am looking for a solution)
I found that the problem indeed is the antivirus "real time file system protection". I do the following to fix the problem:
trace(utils:::unpackPkgZip, edit=TRUE)
I edit line 140 (line 142 in R 3.4.4):
Sys.sleep(0.5)
to:
Sys.sleep(2)
I seems like the antivirus stalls the creation of the package tmp dir. After changing it to 2 seconds the error is gone.
EDIT: to do this programmatically execute
trace(utils:::unpackPkgZip, quote(Sys.sleep(2)), at = which(grepl("Sys.sleep", body(utils:::unpackPkgZip), fixed = TRUE)))
(credits #DavidArenburg)
Just to update everyone, I (think that I) found out the source of the problem: antivirus.
The "real time file system protection" was blocking R from copying the files between folders once they were downloaded.
Upon adding the R directory to the exception list (coupled with adding user permission and installing R on D:\R), and the problem went away. With all of this work, I might as well switch to Linux (I should, really...)
(I updated my post with the above information: http://www.r-statistics.com/2011/04/how-to-upgrade-r-on-windows-7/)
I hope it will help someone in the future,
Tal
If you cannot turn off your antivirus, due to corporate policy for example, here is a workaround that I found. Debugging the unzip package function and then stepping through it gives the antivirus enough time to do its job without interfering. Use this command:
debug(utils:::unpackPkgZip)
install.packages("packageName")
and then step through the code (by pressing enter many times) when R starts debugging during the installation.
I found this solution here.
If you can just download the binary straight from CRAN. On windows when downloaded it will be a zip file. Now manually unzip this into the ..library/ folder of your R (.libPaths()). It worked for me on some packages.
I had this problem installing both swirl and dplyr. I am working on Windows 64-bit.
Warning: unable to move temporary installation
What I did is I accessed my temporary files on the C: drive, and opened my file extractor program and I extracted the files from the temp file in the C: drive to my R program files in the C: drive, by manually copying them. THIS WORKED FOR BOTH dpylr and swirl. Stoked!
Cheers,
Peach
Can you not use the lib.loc parameter to only update packages in your personal library (in user)?
There should be no way to enable a normal, non-augmented user to change files in the program files folder, so the only thing you can do (if you don't want to augment the user) is to have R not updating packages there.
A workaround is to avoid installing R in the program files folder (which may be more or less of a hack than just shifting the library location out of it, depending on your point of view).
Finally, if lib.loc doesn't cut it, you can look at the source code for update.packages and create your own customized version that will always avoid the common library location in program files.
I just met the same question, and the solution I found out was that you should install packages using the original R software (plus, you should choose the right mirror site, some of them are blocked). At first I used Rstudio to install packages and I got the same problem as you met. Hope this is helpful.
I have run into this error several times. In my own case, it is because our admins want us to use remote virtual disks (on Windows 7) for our files and everything is locked up tight as a drum. The only way I can use R packages is in a lib directory on that remote virtual disk. This wouldn't be a problem except that the network isn't always smooth and fast. Thus, when I need a package, especially one with several other packages in tow (e.g., MBESS), I either have to go through the get.packages() process multiple times until it finally finishes or make it IT's headache to do quick like the bunny for me. I can't always wait for IT.
I just went to the library folder (Windows XP) and deleted all fileXXXX folders. Reran the install an it is worked.
I had the same problem. Since the issue seems to be the antivirus blocking the transf of a downloaded file, I tried a different download method in the install.packages and it worked.
For example:
install.packages("stringr", method = "curl")
You must go into the properties of the R folder and change the security parameters. You can enable the option to write and modify for all users.
The error : "unable to move temporary installation" is basically arising due to any of the antivirus running on your system.
Try unzipping the downloaded file from the Temp folder into the default library path (you can get it by running .libPaths() in R session).
I'm using a MRAN and I was having so many versioning issues. Trying to work with tidyverse and ggplot2 and by upgrading to the latest version from Microsoft it solved all of my R-Studio versioning issues.
Version info:
Microsoft R Open 3.5.1
The enhanced R distribution from Microsoft
Default CRAN mirror snapshot taken on 2018-08-01.
Download Microsoft R Open 3.5.1
I have been developing a Cydia tweak called BrightnessControl (I am very new to developing). For now, all it does is use Winterboard to patch var/stash/Applications/Brightness.plist with my modified version. Is there a way, maybe with Theos, that I can patch this file without Winterboard? I am wanting to back this file up somehow and replace it with my modified .plist upon imstall, and then upon un-install delete my modified .plist and restore the original .plist. I have seen something like this done with other tweaks, but I don't know how this is done. May anyone please push me in the right direction?
You don't even need to know programming to do this. The trick is inside the Debian packages' postinst and prerm scripts.
Edit: as per #Nate's comments: beware, because these scripts also run upon updating a package. So, for example, a package with one update which is then removed would do this:
1st installation:
run preinst
(APT installs your package)
run postinst
update:
run prerm of the old version
(APT removes old version)
run postrm of old version
run preinst of new version
(APT installs new version)
run postinst of new version
removal:
run prerm of new version
(APT removes the new version... you no longer have the package)
run postrm of new version