-
Notifications
You must be signed in to change notification settings - Fork 284
Changes to how conda activates/deactivates environments may cause install_keras() to fail. #691
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Should this be moved to rstudio/tensorflow or rstudio/reticulate? |
I corrected the problem by creating a hardlink between .../anaconda3/bin/activate and .../anaconda3/condabin/activate (and the same for deactivate). |
@kevinushey Could you take a look at this one? (should dovetail well w/ the other changes to conda path discovery/munging that are in flight). |
I'll take a look (am mostly OOF this week so may not get to this until next week) |
I have conda version 4.5 and never had this problem... could this be because you specify the conda path like this
Can you just leave out the path to conda (as I always do)? Also, for me with version 4.5 that |
@skeydan wrote:
I encountered the problem using the most up-to-date version of conda, which is conda 4.6.7. I'm unable to comment on earlier versions of conda. I think you have a point regarding my use of the 'conda' argument. I'm running Rstudio server, and install_keras() is unable to find the conda binary unless I explicitly state its location. I am just now realizing that there are two copies of the conda binary: one in .../anaconda3/bin/ and one in .../anaconda3/condabin/. If I run the following:
Then keras/tensorflow installs as expected. Basically, I think this is a case of user (my) error. I pointed install_keras() towards a conda binary, but not the right conda binary. install_keras() assumes that other scripts will be in the same directory as conda, but this wasn't true when I pointed install_keras() to .../anaconda3/condabin/conda. I'm not sure why there is a directory named "condabin" that contains (only) the conda binary. I didn't add it manually. Perhaps it was added when I ran "conda update -all"? -Peter |
I suspect |
@kevinushey thanks, could you put a link to those conda-related changes in @psalveson you're right, after updating |
@kevinushey Note that the tensorflow package has it's own code for installation (as distinct from what is in reticulate) so if we make a fix for anaconda binaries we need to make it in both places. That said, I think we should soon be able to delegate to reticulate from tensorflow so we have only one codepath (but let's not do that just yet). |
Hi @psalveson after the fix to
|
Thanks @skeydan |
@skeydan I seem to be having an another issue after updating reticulate. When I run:
keras_install() exits with the error message:
This happens regardless of whether I use the bin or condabin directories, and it happens with multiple versions of tensorflow (I've tried 1.12.0-gpu, 1.13.0-gpu, and 1.13.1-gpu). traceback() shows:
It looks like conda_binary() is expecting the path of the conda binary, but the environment name is being passed instead. |
I'll take a look! |
Sorry for the trouble. This was indeed a regression in |
I updated reticulate and now when I execute:
It produces the error:
traceback():
I think the problem may have something to do with the argument(s) to conda_python in step 5 above. In my case, the default conda argument ( conda = "auto") fails and conda_python() produces an error . Perhaps explicitly adding the conda argument to conda_python() would fix things? Ex: conda_python(envname = envname, conda = conda) No conda argument vs with conda argument:
DIGRESSION BELOWI'm not sure if this is related or not, but it appears that reticulate isn't able to find my anaconda installation anymore. If I restart R and run:
The output is:
Previously, this would have shown paths for the "base" environment of my anaconda installation of python. UPDATE: I may be mistaken. It appears that reticulate can find my installation of anaconda as long as the environment is not the base/default environment and numpy is installed in the environment. Why is it that reticulate refuses use the the base/default environment of anaconda? I understand that it isn't recommended practice, but maybe use_condaenv() should produce an error rather than appearing to succeed? Also, no error is produced if the condaenv doesn't exist. I'm not sure if this is new behavior or not:
|
|
Thank you. I'll know to add require = TRUE in the future. |
These are edits to a previous comment. Adding them here for visibility.
(output truncated)
traceback():
I think the problem may have something to do with the argument(s) to conda_python in step 5 above. In my case, the default conda argument ( conda = "auto") fails and conda_python() produces an error . Perhaps explicitly adding the conda argument to conda_python() would fix things? Ex: conda_python(envname = envname, conda = conda) No conda argument vs with conda argument:
|
Thanks for continuing to test. I believe rstudio/reticulate@7edf564 should capture what you were recommending; let me know if that helps. |
I updated reticulate and everything appears to be working correctly. Thanks for all your help. |
You're welcome! |
Uh oh!
There was an error while loading. Please reload this page.
The following was produced using R 3.5.2, Rstudio server 1.2 preview, and a new install of Anaconda3 ("conda update --all" run once) on ubuntu 18.04.
I believe there is an issue with using the install_keras() function to install tensorflow/keras to a conda environment. Here's the command I used:
Which produces the following error:
The most recent versions of conda (starting with 4.4) activate and deactivate environments using
conda activate env_name
conda deactivate
Older versions required use of:
source activate env_name
source deactivate
Which has been depreciated and moved to .../anaconda3/bin/, not .../anaconda3/condabin/.
install_keras() appears to be looking in the wrong place for "activate" and "deactivate", which causes installation to fail.
There's some information here about changes to script initialization for conda 4.6.
UPDATE: Please see my comment below for a resolution.
The text was updated successfully, but these errors were encountered: