<ol>
<li>If the environment already exists it will simply be used. You cannot, however, tell it to use an environment with a normal name (e.g., "my_env").</li>
<li>I assume you mean, "where the heck does the random looking conda environment name come from?!?", which is a very good question. The answer to that is that it's a hash of the <code>--conda-prefix</code> setting and the contents of the environment yaml file you specify. The actual code for doing this (I'm "stealing" it <a href="https://github.com/maxplanck-ie/snakepipes/blob/master/bin/snakePipes#L174" rel="nofollow noreferrer">from snakePipes</a>) is:</li>
</ol>

<pre class="lang-py prettyprint-override"><code>import hashlib
md5hash = hashlib.md5()
md5hash.update("what you gave to --conda-prefix".encode())
f = open("your environment yaml file", 'rb')
md5hash.update(f.read())
f.close()
h = md5hash.hexdigest()
</code></pre>

<p><code>h</code> is then the directory name. There are actually two lengths of those, the shorter 8 character version that snakeMake uses by default or the full length version that the code above will produce. snakeMake will actually use either of these. If you're wondering, no I don't think any of this is documented anywhere, you have to dig through the snakeMake code to find it.</p>

CC BY-SA 4.0
2019-09-11T09:53:55.413Z
Ok, that answers the core of my question! 
So if I change the way I refer to the conda-prefix (via symlinks or relative/absolute paths), the environment will get rebuilt. Which is perfectly acceptable as long as you understand what is happening.
guibar
CC BY-SA 4.0
2019-09-11T11:37:34.977Z
Exactly, I'll suggest to Johannes that he document this somewhere :)
Devon Ryan
CC BY-SA 4.0
2019-09-11T14:35:11.350Z
and just to be absolutely clear, if you don't specify a conda-prefix, the hash uses  the yaml file content only, right?
guibar
CC BY-SA 4.0
2019-09-11T14:37:01.460Z
I actually don't know that off-hand, but I presume so. The conda environments end up under `.snakemake` in the output directory, so it's possible that it uses that path somewhere.
Devon Ryan
CC BY-SA 4.0
2020-04-08T09:57:24.197Z
upon the first workflow run I had the `conda` directives in all rules, so that the virtual env was created (relative path to Snakefile is `../outSnakemake_ngs_bngs05b/.snakemake/conda/a87f68b4`). In order to suppress the creation of another (identical) environment I commented all the `conda` directives and called `snakemake -p -s Snakefile_v4_ngs_bngs05b --cluster "qsub -q researshq" -j 5 --use-conda --conda-prefix ../outSnakemake_ngs_bngs05b/.snakemake/conda/a87f68b4`, though the jobs failed. Is this the expected behaviour i.e. can I suppress the `conda` directives by specifying the env?
BCArg
CC BY-SA 4.0
2020-04-08T11:19:14.317Z
If the --conda-prefix doesn't change then an identical env won't be made (it'd have the same hash anyway).
Devon Ryan
CC BY-SA 4.0
2019-09-10T09:45:45.123Z
2019-09-10T09:45:45.123Z
Devon Ryan
<p>I have read this question (<a href="https://bioinformatics.stackexchange.com/questions/6914/running-snakemake-in-one-single-conda-env">Running Snakemake in one single conda env</a>) but still have some doubt.</p>

<p>I am using the '--conda-prefix /some/dir' option and I have a rule in my snakemake file with the directive:</p>

<pre><code>rule xxx:
  ...
  conda:    
    "envs/some.yaml"
  ...
</code></pre>

<p>The first call of that rule will create the conda environment according to the yaml file in /some/dir/envs with some random name (in my case 'bf55a79e'). If I run the workflow in a different directory, the same conda environment (/some/dir/envs/bf55a79e) gets activated directly instead of being built again. So this is what I expected.</p>

<p>My question is: </p>

<ul>
<li>is there some way of skipping the building and specifying that rule xxx should use an already existing conda environment somewhere? </li>
<li>does anyone know where the mapping between rule and directory gets stored?</li>
</ul>

<snakemake><conda>
snakemake with --conda-prefix, can I use a pre-built conda environment?
# snakemake with --conda-prefix, can I use a pre-built conda environment?

(Asked by: username_0 on 2019-09-09)

I have read this question (Running Snakemake in one single conda env) but still have some doubt.
I am using the '--conda-prefix /some/dir' option and I have a rule in my snakemake file with the directive:
rule xxx:
  ...
  conda:    
    "envs/some.yaml"
  ...

The first call of that rule will create the conda environment according to the yaml file in /some/dir/envs with some random name (in my case 'bf55a79e'). If I run the workflow in a different directory, the same conda environment (/some/dir/envs/bf55a79e) gets activated directly instead of being built again. So this is what I expected.
My question is: 

is there some way of skipping the building and specifying that rule xxx should use an already existing conda environment somewhere? 
does anyone know where the mapping between rule and directory gets stored?

**Tags:** snakemake, conda

---

## 1 answers

### Answer by username_1 on 2019-09-10. Score: 3 | Accepted answer

If the environment already exists it will simply be used. You cannot, however, tell it to use an environment with a normal name (e.g., "my_env").
I assume you mean, "where the heck does the random looking conda environment name come from?!?", which is a very good question. The answer to that is that it's a hash of the --conda-prefix setting and the contents of the environment yaml file you specify. The actual code for doing this (I'm "stealing" it from snakePipes) is:

import hashlib
md5hash = hashlib.md5()
md5hash.update("what you gave to --conda-prefix".encode())
f = open("your environment yaml file", 'rb')
md5hash.update(f.read())
f.close()
h = md5hash.hexdigest()

h is then the directory name. There are actually two lengths of those, the shorter 8 character version that snakeMake uses by default or the full length version that the code above will produce. snakeMake will actually use either of these. If you're wondering, no I don't think any of this is documented anywhere, you have to dig through the snakeMake code to find it.

> **Comments:**
> **username_0**: Ok, that answers the core of my question!  So if I change the way I refer to the conda-prefix (via symlinks or relative/absolute paths), the environment will get rebuilt. Which is perfectly acceptable as long as you understand what is happening.  
> **username_1**: Exactly, I'll suggest to Johannes that he document this somewhere :)  
> **username_0**: and just to be absolutely clear, if you don't specify a conda-prefix, the hash uses  the yaml file content only, right?  
> **username_1**: I actually don't know that off-hand, but I presume so. The conda environments end up under `.snakemake` in the output directory, so it's possible that it uses that path somewhere.  
> **username_2**: upon the first workflow run I had the `conda` directives in all rules, so that the virtual env was created (relative path to Snakefile is `../outSnakemake_ngs_bngs05b/.snakemake/conda/a87f68b4`). In order to suppress the creation of another (identical) environment I commented all the `conda` directives and called `snakemake -p -s Snakefile_v4_ngs_bngs05b --cluster "qsub -q researshq" -j 5 --use-conda --conda-prefix ../outSnakemake_ngs_bngs05b/.snakemake/conda/a87f68b4`, though the jobs failed. Is this the expected behaviour i.e. can I suppress the `conda` directives by specifying the env?  
> **username_1**: If the --conda-prefix doesn't change then an identical env won't be made (it'd have the same hash anyway).  

---

