Permission issues in Windows when using simple_python

[dpacheco0921]

When running simple_python on windows 10, It successfully installs the dedicated miniconda python env for R, but I get the following error when installing CloudVolume:

ERROR: Could not install packages due to an OSError: [WinError 5] Access is denied: 'C:\\Users\\Diego\\AppData\\Local\\R-MINI~1\\envs\\R-RETI~1\\Lib\\site-packages\\google\\protobuf\\internal\\_api_implementation.cp36-win_amd64.pyd'
Consider using the `--user` option or check the permissions.

Which I fixed by adding "--user" to the pip_options = "--upgrade --prefer-binary --ignore-installed certifi") hardcoded variable. However, I noticed that for installing some python packages (meshparty) it fails with "--user", but it works when I don't include "--user" in pip_options.

So I was wondering if adding or not '--user' to pip_options could be an input variable to simple_python.

[jefferis]

Thanks for the interest in fafbseg @dpacheco0921 and for this report. I am not a Python expert but I think that one should not use --user with virtual environments. Given this it seems that it would be better to address the problem with permissions on your Windows environment. Can you provide any details about permissions for the path mentioned in the error message. @schlegelp can you provide any insight here?

[schlegelp]

I have next to zero experience with Python on Windows but yes, --user should not be necessary. Actually curious to know where it's installed to with that flag.

[alexanderbates]

@dpacheco0921 , did you manage to fix this issue?

[jefferis]

I assume that you need to make the AppData\\Local\\R-MINI~1\\envs\\R-RETI~1\\Lib\\site-packages folder and all its children writeable. No idea why this isn't the case but I guess some Windows permission issue. Perhaps something to do with admin vs regular users installing apps. Sorry I can't provide more insight ...

[dpacheco0921]

I also thought it was a permission issue in Windows, but the AppData\\Local\\R-MINI~1\\envs\\R-RETI~1\\Lib\\site-packages directory and its children were writeable (and I had administrator permission).

I basically installed manually the packages that failed by trying either of:
ourpip <- function(...) reticulate::py_install(..., pip = T, pip_options = "--upgrade --prefer-binary --user --ignore-installed certifi")
ourpip <- function(...) reticulate::py_install(..., pip = T, pip_options = "--upgrade --prefer-binary --ignore-installed certify")
And for example, then:
ourpip("meshparty")

[jefferis]

Thanks that’s useful @dpacheco0921.

Most likely it’s a lock issue then - two things trying to install the same package at once or more likely something trying to install a library that is already loaded and locked. So start a clean R session and do manual installs as Diego suggests:

ourpip("<troublesomepackagename>")

You could also try:

fafbseg::simple_python(pyinstall="none", "<troublesomepackagename>")

which doesn't require defining any new functions and should still work.

[jefferis]

So, I think this (in a clean session) has a reasonable chance of working round this issue:

fafbseg::simple_python(pyinstall="none", pkgs=c('cloud-volume', 'seatable_api', 'caveclient'))