copy/updating packages when the library is in the user directory

[talgalili]

With respect to the global library, I am using two work machines and both use a folder for my user profile for the R library automatically. It is in my documents \R\win-library\3.2\ (currently)
I think the updateR() will have a problem if the old and new folder are the same. Not sure how you’ll check and avoid that even if the user does decide to migrate the library. I agree that the migration is necessary if the default location for the library is used (under program files…)

[m-stanley]

I'm not sure what the issue is here, but a problem I encounter with R is that my library is in My Documents at C:\Users\m-stanley\Documents\R\win-library\3.4\ or whatever the version number is, and it's never copied over to the new version with installr. That's super annoying - so if that's this issue, I definitely encounter it!

[talgalili]

@m-stanley this is indeed the issue. I'll need to improve the logic of the library detection to solve it, but I don't see how I'll get the time to do it in the near future...

[russHyde]

hi @talgalili , I think I've just hit this problem on my windows laptop too.

Updating from R3.5.1 to R3.6.1

# In R3.5.1
.libPaths()
# [1] C:/Users/russ_/OneDrive/Documents/R/win-library/3.5
# [2] C:/Program Files/R/R-3.5.1/library

All of my non-core R packages are installed in the first of these two libraries (because the Program Files dir is non-writable)

After running installr::updateR() (v 0.22.0) my .libPaths in R3.6.1 is as follows:

# In R 3.6.1
.libPaths()
# [1] C:/Program Files/R/R-3.6.1/library

IfI then use install.packages(some_package) in the fresh R 3.6.1; windows prompts me to start a new personal library. By default this has the same structure as the R3.5 personal library: C:/Users/russ_/OneDrive/Documents/R/win-library/3.6

So I thought I'd be able to copy packages from the .../win-library/3.5 to .../win-library/3.6 using installr::copy.packages.between.libraries but that failed for these two libraries because they didn't have a ./library subdirectory that contained the package definitions.

I rarely use windows for R work, but was wondering whether there might be a way to ensure that packages are transferred from non-standard libraries correctly during installr::updateR()

Happy to help if I can

[talgalili]

I'm sadly not seeing myself fixing this bug in the near future. If you'd like to take a look at it I'd be happy to code review your suggested fixes. Tal

…

On Wed, Oct 9, 2019 at 8:31 PM Russ Hyde ***@***.***> wrote: hi @talgalili <https://github.com/talgalili> , I think I've just hit this problem on my windows laptop too. Updating from R3.5.1 to R3.6.1 # In R3.5.1 .libPaths() # [1] C:/Users/russ_/OneDrive/Documents/R/win-library/3.5 # [2] C:/Program Files/R/R-3.5.1/library All of my non-core R packages are installed in the first of these two libraries (because the Program Files dir is non-writable) After running installr::updateR() (v 0.22.0) my .libPaths in R3.6.1 is as follows: # In R 3.6.1 .libPaths() # [1] C:/Program Files/R/R-3.6.1/library IfI then use install.packages(some_package) in the fresh R 3.6.1; windows prompts me to start a new personal library. By default this has the same structure as the R3.5 personal library: C:/Users/russ_/OneDrive/Documents/R/win-library/3.6 So I thought I'd be able to copy packages from the .../win-library/3.5 to .../win-library/3.6 using installr::copy.packages.between.libraries but that failed for these two libraries because they didn't have a ./library subdirectory that contained the package definitions. I rarely use windows for R work, but was wondering whether there might be a way to ensure that packages are transferred from non-standard libraries correctly during installr::updateR() Happy to help if I can — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#97?email_source=notifications&email_token=AAHOJBXL3DYPYUT2O27WUUTQNYIN3A5CNFSM4DU5OII2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAYVYUY#issuecomment-540105811>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHOJBQUVYVT3UFUFSC3SLTQNYIN3ANCNFSM4DU5OIIQ> .