The assumption last year was that the correct command would be: conda install -c bioconda samtools as it is what was listed at https://anaconda.org/bioconda/samtools. Instead the correct command ended up being: conda install -c bioconda samtools bcftools openssl=1.0 There are 2 different things going on in this command. - Forcing the installation of a specific version of openssl. In this case, a lower version than would normally be installed if samtools were installed by itself. According to https://github.com/bioconda/bioconda-recipes/issues/12100 my understanding is that when the conda package was put together there is an error wherein samtools specifically says to get version 1.1 of openssl, but the samtools program specifically requires version 1.0 to be present.
- We are installing both samtools and bcftools at the same time. This can clean up some installation problems when there are conflicts between individual packages and you want to use them in a single environment. An alternative would be to have a samtools environment and a bcftools environment, but that creates unnecessary steps of having to change environments in the middle of your analysis.
| Expand |
|---|
| title | Click here to expand and see what the outcome of the assumed installation command is, what the problem is, and steps you could take to fix it. |
|---|
|
| Warning |
|---|
| title | This box contains example commands and outputs showing you something that does NOT work for educational and diagnostic purposes. If you use the code listed in this box, be sure you use ALL the code or you may run into downstream problems with this tutorial. |
|---|
|
| Code Block |
|---|
| conda install -c bioconda samtools
samtools --version |
The above command |
will appear appeared to install correctly as other |
programs haveconda installations did, but the second command which you would expect to show |
you the version of samtools instead returns the following error: | No Format |
|---|
samtools: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory |
Googling the entire error the top results clearly |
mention mentioned conda and several pages |
list listed problems associated "fixes" with different conda installation commands |
. : - One of the suggested fixes was to add access to the conda-forge channel (as we have done this year).
|
Other "fixes" involved commands that may work, but at the expense of altering existing packages in our environment (- Additionally, last year the entire course was taught with the hope of sequentially adding new programs to a single growing environment. As mentioned yesterday, such an approach is not always optimal/easy, and hence why this year we are creating a number of additional environments. Working from the assumption that you wanted to keep a single environment, one fix that appeared to be working well based on community feedback was
conda install -c bioconda samtools=1.9 --force-reinstall
|
) while this command may work based on community feedback, the number of - , but at the expense of altering existing packages in the environment. When running the command, the number of programs that would be downgraded
|
is concerning to me. If I were going to go this route, I would instead copy my - was nearly 2 full screens long.
- Rather than jumping to the "force-reinstall" solution it was suggested to copy the existing conda environment to a new "test" environment (conda create --name GVA2021-samtools-test --clone GVA2021)
|
, run the struck-through command listed above, and make sure it works as expected before weighing what exact programs were being downgraded and what the immediate effects would be on other analysis. Most likely I would ultimately rename the environment to something more permanent, and keep samtools as a separate step (conda create --name GVA2021-samtools --clone GVA2021- . Once in the new environment, using the "force-reinstall" command above would have given access to samtools, but would then also require testing other programs in the environment (such as bowtie2, cutadapt, fastqc). Assuming all programs still (seemed) to work you could then rename the environment (
conda create --name GVA2021-V2 --clone GVA2021-samtools-test; conda env remove --
|
name GVA2021name GVA2021-samtools-test). Obviously the more programs that are added, the more likely running into these kinds of conflicts (where different versions of the same dependency are required)
|
Rather than going through all that. My solution is simply to install an older version of samtools deliberately from the start as several webpages suggest that the issue is specific to the 1.12 version)- ), another solution was simply to install an older version of samtools deliberately from the start. In order to do this, I first had to remove the existing (incorrect) samtools version
|
.| Code Block |
|---|
| conda remove samtools
conda install -c bioconda samtools==1.11
samtools --version |
which now gives a reasonable output of: | No Format |
|---|
samtools 1.11
Using htslib 1.11
Copyright (C) 2020 Genome Research Ltd. |
Unfortunately, this would then create a downstream problems with installing bcftools and a different set of conflicts. Therefore we will again remove our (now functioning) samtools package, and install samtools, bcftools, and openssl version 1.0 in a single command. | Code Block |
|---|
| conda remove samtools
conda install -c bioconda samtools bcftools openssl=1.0- (
conda remove samtools) and then specify the older version we wanted to use (conda install -c bioconda samtools==1.11). This then allowed the samtools --version command to give expected output of version 1.11 Unfortunately, during testing it quickly became obvious that the next program to install (bcftools) was going to create an entirely new set of installation problems meaning that samtools again hat to be uninstalled and both samtools and bcftools installed together. conda remove samtools ; conda install -c bioconda samtools bcftools.
|
|
|