I installed Conda at a different location than the default location on Ubuntu 16.4 using the official installation helper.
Now conda create and source activate works, but source deactivate gives me the error:
(deep) yuqiong#yuqiong-G7-7588:/media/yuqiong/DATA$ source deactivate
bash: deactivate: No such file or directory
I checked this issue on Github: #458: "Using source deactivate on a conda env fails unless the root anaconda directory is in PATH". It seems to be related, but I do not understand what happens when I run source deactivate inside a conda environment. Is it because something is wrong with my PATH variables?
Here is the part of my /.bashrc related to Conda, if helpful.
Thanks so much for your help!
# added by Anaconda3 5.3.1 installer
# >>> conda init >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$(CONDA_REPORT_ERRORS=false '/media/yuqiong/DATA/Anaconda3/bin/conda' shell.bash hook 2> /dev/null)"
if [ $? -eq 0 ]; then
\eval "$__conda_setup"
else
if [ -f "/media/yuqiong/DATA/Anaconda3/etc/profile.d/conda.sh" ]; then
. "/media/yuqiong/DATA/Anaconda3/etc/profile.d/conda.sh"
CONDA_CHANGEPS1=false conda activate base
else
\export PATH="/media/yuqiong/DATA/Anaconda3/bin:$PATH"
fi
fi
unset __conda_setup
# <<< conda init <<<
### conda shortcuts
function actv() {
#do things with parameters like $1 such as
source activate "$1"
}
So I still have not figured out why source deactivate does not work anymore, but the good thing is conda deactivate works. I'm sticking with that now.
And I think the problem is I do not understand how conda works... Here is a gentle intro to package manager if anyone's interested...https://medium.com/#sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527
Use
conda deactivate
To deactivate or to go to the base source and then you can use
conda info --envs
to get the list of available sources
source activate <source_name>
and to activate a particular source.
Refer this for more -> Managing environments - conda.io
Just Put
conda deactivate
good to know
conda activate and conda deactivate only work on conda 4.6 and later versions
Related
I have just installed a new version of Conda (22.9.0). My previous version used to prepend the Linux prompt with the name of the activated Conda environment. However the new version replaces the whole prompt with the Conda environment name e.g. (base) . Therefore, I would like to customise the prompt. I have done this using the env_prompt option in the .condarc, however I am struggling to add a space at the end of the prompt.
channels:
- bioconda
- conda-forge
- defaults
auto_activate_base: false
env_prompt: ({default_env}) [\u#\h \W]\$
I would like to add a space after the dollar sign but I can't work out how to do this. Help would be appreciated.
Best wishes,
Lucy
Conda 22.9.0 introduced a minor regression resulting in your prompt being incorrectly modified. Running a one-time re-initialization of conda will fix the issue:
conda init bash
After running the above command, you will need to restart your shell for the changes to take effect.
See: https://github.com/conda/conda/issues/11885
Detailed info here, tl;dr can be found towards the end...
I've got a bioinformatics workflow I run using snakemake, with a python3 wrapper script using the snakemake API so that the snakemake command is simplified (https://github.com/charlesfoster/covid-illumina-snakemake). Most necessary programs are installed in a 'master' conda environment, while other programs with incompatible dependencies are installed in dedicated environments using conda directives within snakemake rules.
However, some programs cannot be easily included in this manner because they have a more complex installation. An example is pangolin (https://github.com/cov-lineages/pangolin), which requires the pangolin repo to be cloned, a conda environment created, then a "pip install .". Then, to run pangolin within the workflow, I have the following rule:
rule pangolin:
input:
fasta=os.path.join(RESULT_DIR, "{sample}/variants/{sample}.consensus.fa"),
output:
report=os.path.join(RESULT_DIR, "{sample}/pangolin/{sample}.lineage_report.csv"),
shell:
"""
set +eu
eval "$(conda shell.bash hook)" && conda activate pangolin && pangolin --outfile {output.report} {input.fasta} &> /dev/null
set -eu
"""
I've also tried the new named conda environment directive as of snakemake version ~6.15.5:
rule pangolin:
input:
fasta=os.path.join(RESULT_DIR, "{sample}/variants/{sample}.consensus.fa"),
output:
report=os.path.join(RESULT_DIR, "{sample}/pangolin/{sample}.lineage_report.csv"),
conda:
"pangolin"
shell:
"""
pangolin --outfile {output.report} {input.fasta} &> /dev/null
"""
Steps to run the workflow:
conda activate CIS
CIS [options] directory_name/
While this works on my main development PC, when I try to install the pipeline on a new computer, I end up getting the following error:
Could not find conda environment: pangolin
You can list all discoverable environments with `conda info --envs`.
If I run conda info --envs manually within the terminal, I get the following:
$USER/Programs/covid-illumina-snakemake/.snakemake/conda/520fff074cd181af7ee385f2520fdd81
$USER/Programs/covid-illumina-snakemake/.snakemake/conda/cb6755e5de757f643e542e3ec52055b7
base $USER/miniconda3
CIS * $USER/miniconda3/envs/CIS
pangolin $USER/miniconda3/envs/pangolin
If I run conda info --envs within the snakemake workflow itself, I get the following:
$USER/Programs/covid-illumina-snakemake/.snakemake/conda/520fff074cd181af7ee385f2520fdd81
$USER/Programs/covid-illumina-snakemake/.snakemake/conda/cb6755e5de757f643e542e3ec52055b7
$USER/miniconda3
base * $USER/miniconda3/envs/CIS
$USER/miniconda3/envs/pangolin
(username redacted here in both for brevity)
So, as you can see, the names of the environments are no longer detected within the snakemake workflow, and the 'CIS' environment is incorrectly thought to be 'base'. Therefore, the pangolin conda environment cannot be activated by name with eval "$(conda shell.bash hook)" && conda activate pangolin.
tl;dr: conda info --envs has unexpected and different behaviour when invoked from within a snakemake workflow, which is 'driven' by a python script within a 'master' conda env.
Does anyone know why this might be, and/or how to fix it? Is there a better way to activate a named conda environment within a snakemake workflow?
Thanks!
snakemake version: 6.15.5
conda version: 4.11.0
I recently updated my 2019 macbook pro to macos big sur version 11.3. Before the update I had anaconda installed, had created virtual python 3 environments, installed jupyter notebook, and had added conda to my python path variable. I was able to activate conda env and launch jupyter notebook servers. I updated to big sur version 11.3 and now when I try to do anything with conda all I get is:
-bash: conda: command not found
I saw some posts that the issue may be caused by zsh being the new default. So I tried the commands below. Also tried switching my default terminal to zsh, but nothing has worked. So I switched back to bash.
Does anyone know what the issue might be and can you suggest how to fix it?
tried:
/System/Volumes/Data/anaconda3/bin/conda init zsh
tried:
source /System/Volumes/Data/anaconda3/bin/activate
output:
-bash: /System/Volumes/Data/anaconda3/bin/conda: /anaconda3/bin/python: bad interpreter: No such file or directory
code:
vim ~/.bash_profile
output:
# added by Anaconda3 2019.03 installer
# >>> conda init >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$(CONDA_REPORT_ERRORS=false '/anaconda3/bin/conda' shell.bash hook 2> /dev/null)"
if [ $? -eq 0 ]; then
\eval "$__conda_setup"
else
if [ -f "/anaconda3/etc/profile.d/conda.sh" ]; then
. "/anaconda3/etc/profile.d/conda.sh"
CONDA_CHANGEPS1=false conda activate base
else
\export PATH="/anaconda3/bin:$PATH"
fi
fi
unset __conda_setup
# <<< conda init <<<
~
~
~
~
~
update:
I tried the first suggestion in the link below,
"source /System/Volumes/Data/anaconda3/bin/activate"
But got the usual conda not found.
Mas OS Big Sur update - Python3 / conda / pip not found
My anaconda home does seem to be in the same location mentioned in the second answer from the post above
"/System/Volumes/Data/anaconda3"
so maybe that's the issue.
Update:
tried updating path in bash_profile as below
got error below
conda info
-bash: /anaconda3/bin/conda: No such file or directory
# added by Anaconda3 2019.03 installer
# >>> conda init >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$(CONDA_REPORT_ERRORS=false '/System/Volumes/Data/anaconda3/bin/conda' shell.bash hook 2> /dev/null)"
if [ $? -eq 0 ]; then
\eval "$__conda_setup"
else
if [ -f "/System/Volumes/Data/anaconda3/etc/profile.d/conda.sh" ]; then
. "/System/Volumes/Data/anaconda3/etc/profile.d/conda.sh"
CONDA_CHANGEPS1=false conda activate base
else
\export PATH="/System/Volumes/Data/anaconda3/bin:$PATH"
fi
fi
unset __conda_setup
# <<< conda init <<<
~
~
~
~
~
~
Try to find where all the condas are and then proceed accordingly (i.e. change the path in your scripts):
find / -name "*conda*" 2>/dev/null
so after much googling, hacking, and swearing I got the second solution on this link to work:
Mas OS Big Sur update - Python3 / conda / pip not found
move your anaconda3
run the prefix rehome tool
re-initialize your conda
I got the same problem when switching to Monterey and downloading Anaconda on it. Tried lots of commands but all failed, having different problems like conda commands not found/couldn't run python script/couldn't reinstall Anaconda/python etc. It took me hours to figure out the simplest solution is just to type "chsh -s /bin/zsh" to switch to zsh...I didn't even know bash and zsh would cause such problem
I am writing a bash script with the objective of hosting it on a computing cluster. I want the script to create a conda environment for whichever user executes it, so that everyone on our team can quickly set-up the same working environment.
I realize this is a bit overkill for the number of commands necessary but I wanted to practice some bash scripting. Here is my script so far:
#!/bin/bash
# Load anaconda
module load Anaconda/4.2.0
# Create environment
conda create -n ADNI
# Load environment
source activate ADNI
# Install image processing software
pip install med2image
echo 'A working environment named ADNI has been created.'
echo 'Please run `source activate ADNI` to work in it.'
This script creates the environment successfully. However, once I load the environment after running the script, I run conda list to see which packages are loaded within it and get the following output:
(ADNI) MLG-BH0039:ADNI_DeepLearning johnca$ conda list
# packages in environment at /Users/johnca/miniconda3/envs/ADNI:
#
(ADNI) MLG-BH0039:ADNI_DeepLearning johnca$
This gives me the impression that the environment has no packages loaded in it. Is this correct? If so, how can I alter the script so that the desired packages successfully install into the specified environment.
Thanks!
I managed to find a better way to automate this process by creating an environment.yml file with all the desired packages. This can include pip packages as well. My file looks like this:
name: ADNI
channels:
- soumith
- defaults
dependencies:
- ca-certificates=2017.08.26=h1d4fec5_0
- certifi=2017.11.5=py36hf29ccca_0
- cffi=1.11.2=py36h2825082_0
- freetype=2.8=hab7d2ae_1
- intel-openmp=2018.0.0=hc7b2577_8
- jpeg=9b=h024ee3a_2
- libffi=3.2.1=hd88cf55_4
- libgcc=7.2.0=h69d50b8_2
- libgcc-ng=7.2.0=h7cc24e2_2
- libgfortran-ng=7.2.0=h9f7466a_2
- libpng=1.6.32=hbd3595f_4
- libstdcxx-ng=7.2.0=h7a57d05_2
- libtiff=4.0.9=h28f6b97_0
- mkl=2018.0.1=h19d6760_4
- numpy=1.13.3=py36ha12f23b_0
- olefile=0.44=py36h79f9f78_0
- openssl=1.0.2n=hb7f436b_0
- pillow=4.2.1=py36h9119f52_0
- pip=9.0.1=py36h6c6f9ce_4
- pycparser=2.18=py36hf9f622e_1
- python=3.6.0=0
- readline=6.2=2
- scipy=1.0.0=py36hbf646e7_0
- setuptools=36.5.0=py36he42e2e1_0
- six=1.11.0=py36h372c433_1
- sqlite=3.13.0=0
- tk=8.5.18=0
- wheel=0.30.0=py36hfd4bba0_1
- xz=5.2.3=h55aa19d_2
- zlib=1.2.11=ha838bed_2
- pytorch=0.2.0=py36hf0d2509_4cu75
- torchvision=0.1.9=py36h7584368_1
- pip:
- cycler==0.10.0
I can then automate creating the environment by referencing this file, as in:
#!/bin/bash
# Load anaconda
module load Anaconda/4.2.0
# Create environment
conda env create -f adni_env.yml
echo ' '
echo 'A working environment named ADNI has been created or updated.'
echo 'If working on the cadillac server please `module load Anaconda/4.2.0`.'
echo 'Then run `source activate ADNI` to work within the environment.'
echo ' '
I hope this can help anyone in the future who may have similar issues.
The command
conda create -n ADNI
creates an environment with no packages installed, not even Python or pip. Therefore, despite activating the environment, you are still using some other pip that appears on your PATH. You need to install pip or Python into the environment first, either when the environment is created or afterwards with the conda install command
conda create -n ADNI python=3.6
will install Python, which brings along pip when the environment is created or
conda create -n ADNI
conda install -n ADNI python=3.6
will install Python afterwards.
In the best case, you would use conda to install that package. It isn't all that difficult to create a conda package from a pip package and upload it to a channel on Anaconda.org so your team can access it.
I just began to use pyenv to manage my python versions, and began to use the pyenv virtualenv plugin to manage my virtualenvs, and so far, I have loved it. One thing I miss however, is that with virtualenv, you could actually place virtual environments in repository directories so that your repository was a completely reproducible environment. Does anyone know of a way to choose the directory of your virtualenv in pyenv?
Short answer: You can’t, as far as I know.
It wouldn’t really work either, right? If you use pyenv virtualenv to install a virtualenv into a repo, and you clone that repo to another machine… how would pyenv on the new machine know to take control of the virtualenv in the repository?
Also, “you probably shouldn’t do that”. Virtualenvs are not 100% decoupled from the underlying Python installation, and aren’t really all that portable. And do you really want to litter your repositories with a bunch of easily replicated junk? The “right” way to go about things is probably to to maintain a requirements.txt for pip — that way you can easily reproduce your development environment wherever you clone your repo.
That all said, there’s nothing stopping you from using plain old virtualenv to create a virtualenv anywhere you like, even if you installed virtualenv into a Python interpreter under pyenv control. That virtualenv itself will of course not be administered by pyenv, but you can still use it as you always did…
Here is a GitHub issue on the project tracker asking about this: https://github.com/pyenv/pyenv/issues/802
The reply by a project collaborator was:
You can just create virtualenv in any location. To use it from pyenv, create symlink to the environment in ~/.pyenv/versions
although I must say I'm not very satisfied with this solution.
There's a workaround
In your project directory, create a .python-version file. Assuming you already installed some virtual environment using pyenv-virtualenv, then append this line to it(you may want to change the version number):
3.7.1/envs/your-project-name#3.7.1
Whenever you enter into the directory, the correct python version will be used, and it works pretty well.
How about:
pyenv install -s 3.8.3 # install preferred version if needed
PYENV_VERSION=3.8.3 python -m venv /tmp/your/prefered/dir ; source /tmp/your/prefered/dir/activate
Note that this method uses venv, not virtualenv, which is slightly different, but a part of a standard library.
Slightly left-field answer, but I ended up writing a hacky equivalent of pyenv that looks for a virtualenv in a directory and its parents because pyenv doesn't really seem to support this as layed out in the answer about.
I called this script enpy, put it on my path and then called e.g. enpy -c import sys; print(sys.executable)
#!/usr/bin/python3
import os
import sys
from pathlib import Path
NAMES = ("venv", "env", ".env", ".venv")
def find_python():
cwd = Path(os.getcwd())
for direc in [cwd] + list(cwd.parents):
for p in NAMES:
venv = direc / p
if venv.exists():
return venv / "bin" / "python"
else:
raise Exception("Could not find python")
python = find_python()
os.execvp(str(python), [str(python)] + sys.argv[1:])
To build on-top of a previous comment, you can add this to your .zshrc:
pyCreate () {
if [ -d .venv ];then
rm -rf .venv; fi &&
if [ -f .python-version ];then
pyVersion="local"
else
pyVersion="global"; fi &&
location=${1:-requirements.txt} &&
if [ -f $location ];then
action=(pip install -r $location)
else
action=(echo "\n No file: $location \n"); fi &&
PYENV_VERSION=`pyenv $pyVersion` python -m venv .venv &&
source .venv/bin/activate &&
pip install --upgrade pip && $action
}
I use the simple recipe of
python -m venv virt to create the local venv
Link the venv to pyenv with ln -s <local virt> ~/.pyenv/versions/<venv name>
Now you can do pyenv local <venv name> and all other normal operations from pyenv with this venv.
For the interested I have made two CLIs
pyenv-here to create a new venv and set local dir in one go
pyenv-link to link a local virt to pyenv
The top comment is wrong; you certainly can.
Once you create your virtual environment with pyenv virtualenv 3.9.15 your-environment-name, you can specify the directories in which this environment will be used automatically with the following command. In your desired directory, run:
pyenv local your-environment-name
The command will create the necessary .python-version file that includes the name of your environment. From now on, every time you enter the folder, the specified environment will be used.
If you want to just use pyenv specific python version and create virtual env from it in wanted directory, you can for example do this:
~/.pyenv/versions/3.10.8/bin/python -m venv my/path/to/venv