I have qiime2 program https://qiime2.org in my directory /home/owner/anaconda3/envs/qiime2-2019.1. In Linux terminal, I run source activate /home/owner/anaconda3/envs/qiime2-2019.1 to start this program.
I tried doing this within R studio as system('source activate /home/owner/anaconda3/envs/qiime2-2019.1'), but it it gives me this error: sh: 1: activate: not found
Warning message:
In system('activate /home/owner/anaconda3/envs/qiime2-2019.1') :
error in running command
Is there a way to activate anaconda env within R or Rstudio?
Yes there are multiple ways I recommend looking into the reticulate package but basically, R Studio preview 1.2 is capable of "finding" your conda environments.
My prefered way is:
library(reticulate)
library(tidyverse)
# Seeing your enviroments
conda_list()
#Using it
conda_list()[[1]][1] %>%
use_condaenv(required = TRUE)
#Checking python
import platform
print(platform.python_version())
Links
Reticulate: https://rstudio.github.io/reticulate/
My blog: https://twosidesdata.netlify.com/2019/03/23/exploratory-data-analysis-basic-pandas-and-dplyr/#how-to-set-up-reticulate
I think it could not be successful to enter the conda environment in R console, but you still can use the environment command by indicating the path.
For instance, my path of qiime is /home/username/miniconda3/envs/qiime2-2019.7/bin/qiime.
If you want to run the code like qiime info, you can use the command:
system("/home/username/miniconda3/envs/qiime2-2019.7/bin/qiime info")
Generally, I do not use Rstudio but from some searches, I can suggest you try by setting python path instead of activating environment by Conda activate.
You can select which python interpreter you are going to use and here it.
library(reticulate)
path_to_python <- "/anaconda3/envs/qiime2-2019.1/python"
use_python(path_to_python, required = TRUE)
here are some answers for the same type of question:
1> https://stackoverflow.com/a/54813273/9071644
2> https://stackoverflow.com/a/45891929/9071644
3> https://stackoverflow.com/a/43411909/9071644
I know this is an old question, but found some ways one can activate. One is using the library reticulate mentioned above, but I use it this way:
library(reticulate)
use_condaenv("py2_env") #activate an environment e.g py2_env
base::system(paste0("sh py2_env_program_to_run.sh")) #run a program that requires that environment
With reticulate im not sure though how you would deactivate the environment.
The second way, I wrote a little bash script called 'env_eval.sh'
#!/bin/bash
PATH=/opt/conda/bin:$PATH
export PATH
eval "$(conda shell.bash hook)"
Then I reference it in my R script everytime i want to use conda e.g:
base::system2(paste0("sh ",run_folder,"/code/bash/env_eval.sh conda activate py2_env && run_py2_env_program.sh"))
I can even deactivate a conda environment with this method:
base::system(paste0("sh ",run_folder,"/code/bash/env_eval.sh conda deactivate && run_program_that_should_not_be_in_any_conda_env.sh"))
If you want to use Python in RStudio, the best way to get it going is to create a separate 'reticulate' environment using Anaconda.
Part of the reason is that so you can use RMarkdown for your output requires PyQt5 which will break your Jupyter/Spyder environments if you overwrite PyQt.
Then you have to make an .Renviron file like this setup. which points R to the proper Python env. Otherwise, the default for RStudio seems to be a miniconda environment.
Once your separate reticulate environment is set and you have .Renviron pointing to it, all of your Python package installs should go into that environment.
Related
I'm trying to build a dashboard app via Plotly.Dash.
Therefore, I'm transitioning from using Jupyter to Atom.ide.
It seems I have managed to set up a virtual environment and activated it with no errors; in that virtual environment dash_reqlibs.yml i'm trying to install Plotly lib, which also loads with no errors according to terminal:
After the installation i'm trying to run my simple test code and it tells me it doesn't see module plotly:
Now, please note, that according to my research I'm not even supposed to do that since in my dash_reqlibs.yml I have specified all need - doesn't work either way though:
UPDATE:
Removed bad venv
Created new one successfully
Changed to app.py directory and activated the venv
cannot select venv as it doesnt show up
Try creating environment from the beginning again, using these steps:
Create “dash_reqlibs.yml” file with required libraries
Save it inside your Environments folder (or whatever name you call that folder)
Open Windows Command Prompt (or Atom terminal) and ‘cd’ into your Environments folder
Crate new virtual environment by typing: conda env create -f dash_reqlibs.yml
Activate your new environment:
a. On Windows, type: conda activate env_dash (name value inside the .yml file)
Let me know how it goes.
I'm using emacs and anaconda.
I have this in my init.el:
(setenv "WORKON_HOME" "/home/user/anaconda3/envs/")
And conda on my path:
# added by Anaconda3 installer
export PATH="/home/user/anaconda3/bin:$PATH"
but emacs can't find my conda environments, which I understand it is supposed to be able to do..
So, when I run C-c C-p to start a new session, and C-c C-c, it fails to import my packages which are installed in a conda environment, with ModuleNotFoundError.
Since I have added this to my path and it still doesn't work, I am trying to work around this, and still be able to run my conda applications from emacs.
I can open a shell in emacs with M-x shell, then source activate myenv, and run python.
I now want C-c C-c to copy into /this/ shell. How do I mark this shell buffer as a python process to send my file.py's text to on C-c C-c, rather than just a shell shell?
Update1
I've also looked at the following references:
https://emacs.stackexchange.com/questions/20092/using-conda-environments-in-emacs
How does conda-env list / conda info --envs find environments?
But neither package works for me. I still get, when I try:
conda-env-list
*Conda envs*
Produces a blank buffer.
And this for pyvenv-workon:
pyvenv-workon
Work on: (empty)
These environments very much exist, and it makes it impossible to use emacs as a python IDE if I can't run my code.
What I found works for me is to use the conda package from ELPA and set two of its configuration variables to point to my Conda directory. The following snippet does the trick in my .emacs:
(use-package conda
:ensure t
:init
(setq conda-anaconda-home (expand-file-name "~/miniconda3"))
(setq conda-env-home-directory (expand-file-name "~/miniconda3")))
conda-anaconda-home is the equivalent to the ANACONDA_HOME environment variable (i.e. contains all files of your Anaconda installation)
conda-env-home-directory - is the directory where your virtual environments get stored (within the envs subdirectory)
With this configuration I'm able to run M-x conda-env-activate and have access to all previously created envs.
Programs inherit the environment variables from the shell that spawned them. The way conda and virtualenv work is by overriding the shell's PATH variable. They do this so that the OS finds the new version of the app (conda's or virtualenv's) instead of the default one installed with the OS (Macs come with an ancient version of python).
So, what is happening here? If you start Emacs by double clicking on the OS icon it will inherit the default shell environment variables. So when you try to call a library that you installed with conda (or equivalently with virtualenv and pip), because you are using the default OS path, the OS is finding the default version of python (and crucially the default version's libraries). The default version of python is going to respond "I have no idea what library that is."
How to fix? One reliable way is to not start Emacs by double clicking on the OS Icon. Here is what I do most days:
1) start a console/terminal
2) switch to the conda environment `activate py37`
(or with virtualenv: `source .py37dev/bin/activate`)
3) start Emacs from that same shell that has the modified environment variables.
On a Mac its: `/Applications/Emacs.app/Contents/MacOS/Emacs`
(I use a installed version of Emacs on the Mac because the one that
comes with Mac is ancient).
On Linux and Windows the path to EMacs will be different but the idea is the same.
4) start a shell inside Emacs and you should see the shell looks the way it does
in your conda shell (or virtualenv shell)
here it what it looks like for me:
see how the version of python is not the default OS python? Its the one from the virtualenv + pip environment (conda works the exact same way, just the start envirmonment is a different command)
I tested the solutions given in the answers of Wojciech Gac, of Mittenchops and James Anderson.
While solution of James Anderson's solution is by far the easiest, it comes with a few problems:
First, you have to reactivate the environment in each shell process you spawn in emacs. There is also the possibility that emacs has a different pythonpath, therefor reluctantly using system python and not venv python.
The solution with conda.el is somehow weird. In Melpa it is listed as obsolete and with instructions of https://github.com/necaris/conda.el it won't recognize the environments on my certain machine.
On the same machine the solution with pyenv as mentioned in https://emacs.stackexchange.com/a/20093/28567 is working like a charm.
Therefor you only need to install with M-x package-install search for pyenv and then insert following two lines into .emacs:
(setenv "WORKON_HOME" "~/anaconda3/envs") ; /anaconda3 || /miniconda || wathever path your conda installation is located at
(pyvenv-mode 1)
This is my minimal solution to this problem:
create a batch file like this
conda activate <yourEnv>
python -i
set (local) python-shell-interpreter pointing to the batch-file
run-python as always (C-c C-p ...)
I know this is not exactly an answer to your question. But If you JUST want to run your code, open the directory in the terminal where your files are located (e.g. cd /Downloads/Chapter01/yourfile.py) . Then, activate the environment (conda activate *your env*) and pass this command (python yourfile.py). Your code will be executed within that environment by python.
I edit remote files with emacs and run code like this in another terminal window. You may wanna open the two terminal windows side by side while debugging your code.
I am finding that when I create a Conda environment source activate environment and then deactivate that environment source deactivate environment, my native bash commands no longer work.
I've attached an image of ls working before enabling an environment and then not afterwards. I assume that this is something because of my PATH - but I am a novice and am not sure specifically what to fix. I am doing this in Git Bash on Windows. Anaconda 3 and Python 3.5.
Please work ls, come on
Most probably your conda environment is replacing the parameters and environment variables defined in your local bash profile. I am sure if you open a new environment(bash session), you will find everything is working fine.
I would suggest you add a command to reload bash profile after deactivating the environment, so that the profile variable values will again be applied. It should solve the problem.
There are a few bugs in the activate/deactivate scripts, which I've fixed in versions I call activate.cygwin and deactivate.cygwin.
activate.cygwin: fixes 2 places where the conda command returns a string with a return "\r" at the end that confounds processing.
deactivate.cygwin: fixes conversion of /cygdrive/... to avoid error
CondaValueError: Could not find environment: /cygdrivec:\Users\rjp\Anaconda2\envs...
I've posted the modified scripts to https://bitbucket.org/snippets/plevin/. See instructions at the top of activate.cygwin.
The correct way to deactivate a conda environment is to run conda deactivate, rather than source deactivate environment
Source: https://docs.conda.io/projects/conda/en/latest/user-guide/tasks/manage-environments.html?highlight=activate#deactivating-an-environment
I use Git Bash in Windows 10 and encountered the same problem too. The previous answer does not work for me, probably because I don't have any path set in ~/.bash_profile and ~/.bashrc.
I checked my path variable in a fresh git bash, it looks like:
/c/Users/chen_x/bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/mingw64/bin:/usr/bin:/c/Users/chen_x/bin....(more)
After . C:/Users/chen_x/Miniconda3/Scripts/activate C:/Users/chen_x/Miniconda3 and . activate snowflakes, the path becomes:
/C/Users/chen_x/Miniconda3/envs/snowflakes:(blalbla..):C:\Users\chen_x\Miniconda3\Library\bin;C:\Users\chen_x\Miniconda3;....(more)
I assume that git bash does not recognize pathes like C:\program files..., then added the following line to C:/Users/chen_x/Miniconda3/Scripts/activate right after the last EXPORT PATH= command (about line 78):
export PATH="$($_CONDA_PYTHON -c "import re; p=re.sub(r'\\\', r'/', r'$PATH'); p=re.sub('(;|:)([A-Z]):', lambda m: ':/'+m.group(2).lower(), p); print(p)")"
It works.
By the way, I create a ~/condaenv script to start conda environment:
#!/bin/bash
. C:/Users/chen_x/Miniconda3/Scripts/activate C:/Users/chen_x/Miniconda3
It would be convinent to :
. ~/condaenv
. activate snowflakes
I have installed anaconda on a Linux machine. I noticed that after deactivating the anaconda environment with:
source deactivate
When running:
which python
I get:
/home/user/anaconda/bin/python
Instead of
/usr/bin/python
How can I restore this setting?
The comments somewhat cover the answer to the question, but to clarify:
When you installed Anaconda you must have agreed to have it added to your PATH. You'll want to check in your ~/.bash* files and look for any export PATH= lines to check this. So Anaconda is always on your path. The source deactivate command will only deactivate "sub" Conda environments. It will never remove what is called the "root" Conda environment (the one you originally installed). If you don't want Anaconda on your PATH by default then remove it from your ~/.bash* startup files. Then when you want to use Anaconda you'll need to add it to your PATH. Or just add the specific Conda environment you are interested in to your PATH directly, and don't worry about the activate and deactivate scripts. At their core all they do is modify PATH.
I hope that helps clarify things.
Anaconda comes with its own everything, and they ask if you wish to use their software as a default when you install it by adding their bin first to your PATH variable. If you do that, you can only manually remove it later from .bashrc to undo this action.
I chose not to do it, but i made a shell script to start spyder and use the anaconda distribution when i wish to, without altering my PATH by calling spyder like this from the shell script:
PATH=/home/<... path to where i installed anaconda>/bin:$PATH spyder &
This means that i am adding their distribution's bin to the path only for the extent of running that command (spyder), otherwise my environment is unaffected by anaconda.
If i wish to add things to it, i pass an option to the shell when i source it and that triggers these actions:
PATH=/home/<... path to where i installed anaconda>/bin:$PATH
PS1='\[\033[1;34m\](A)\w:\[\033[0m\] '
so that i see (with colors!) that in this terminal i am using an altered PATH, the one with python3 and such from anaconda, etc... When done, i kill the terminal! :)
To get back to the former default, I comment out the entry setting the pathbin the .bashrc file and get these results:
$ which python
/usr/bin/python
$ python -v
python 2.7.*
If you have installed something, you want to use it before older installs, in general.
Your path is well set: your install is searched before system install.
If you want to use system python, run % /usr/bin/python.
If you don't want anaconda, just trash it (or move it somewhere ouside of path).
This may help:
% which -a python.
I successfully created two separate Python environments in Anaconda, yet seem to be unable to activate either one of them. I have tried to read up on this topic as much as possible here on Stackoverflow, yet no solution did resolve my issue. I added information asked for by comments in this question (Anaconda Environment Doesnt activate).
When trying to activate an environment, the console output is -bash: activate: No such file or directory.
The output of which conda is /Users/username/anaconda3/bin/conda.
The output of type source is source is a shell builtin.
When trying which activate, the shell returns nothing.
In my bin folder, I also seem not to have an activate executable, but only one which is called activate-global-python-argcomplete.
Why do I lack the standard activate file and how I could resolve this issue best?
I experience a similar problem. In my case, the problem is related to the use of the tcsh, but activate only supports bash and zsh.
You can check your current used shell with the command
echo $0.
You have to use a compatible shell in order to use the source activate command.
I think you happened to install a buggy version of anaconda which was quickly patched.
conda update conda
should get you back up and running.
Start a new terminal and try again. Alternatively, type hash -r and see if it helps.
Do not do this!!!, this broke my dnf
First I tried to point source to a activate file,
source /usr/lib64/python3.6/venv/scripts/common/activate environment
That appeared to work, but no actual values got updated. I tried the answer by mattexx, but it complained conda wasn't installed, so I used.
conda install conda
I had to have root permission since it was being installed to the root environment, but after that everything appears to work.
That is what broke my fedora installation
tcsh was the problem for me. Changed to bash and all is ok.
In this case, the problem might be that the virtual environment was created in /Users/username/anaconda3/envs/ and hence the activate will be in:
/Users/username/anaconda3/envs/NAME_OF_YOUR_VIRTUAL_ENV/bin/activate
Hence to activate the environment you could run:
source /Users/username/anaconda3/envs/NAME_OF_YOUR_VIRTUAL_ENV/bin/activate
My problem was that file /opt/pycharm/plugins/terminal/.zshrc (using ZSH) contained line source $JEDITERM_SOURCE. That variable contained correct paths as two parameters <path-to-anaconda-activate>/activate <path-to-anaconda>, but apparently they got interpreted as a single parameter: <path-to-anaconda-activate>/activate <path-to-anaconda>.
I solved that prepending eval to that line, making it eval source $JEDITERM_SOURCE. Now, the variable expands correctly.
If you're using bash then make the same change to /opt/pycharm/plugins/terminal/jediterm-bash.in.
I'm using the bash shell inside pycharm and fixed the problem by making this change:
[~/opt/pycharm-community/plugins/terminal]$ diff jediterm-bash.in.old jediterm-bash.in
65c65
< source "$JEDITERM_SOURCE"
---
> eval source "$JEDITERM_SOURCE"
Essentially making the same change recommended above by https://stackoverflow.com/users/1564931/netchkin, but to ~/opt/pycharm-community/plugins/terminal/jediterm-bash.in.
This fixed my existing projects. But any new projects don't seem to try and activate the conda environment at all. It seems as if new projects created in Pycharm 2017.1.2 don't set the JEDITERM_SOURCE variable when starting a session in the terminal plugin.
There is an open issue on this at https://youtrack.jetbrains.com/issue/PY-23417
Looks like there was a big change to the conda activate script in version 4.4.0. See https://conda.io/docs/release-notes.html. If I downgrade conda to 4.3.34 then I can get conda virtual environments to work in the pycharm terminal again.