Skip to content
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

Installation problem with mamba #194

Open
3nrique0 opened this issue Feb 4, 2025 · 7 comments
Open

Installation problem with mamba #194

3nrique0 opened this issue Feb 4, 2025 · 7 comments
Assignees
Labels
bug Something isn't working

Comments

@3nrique0
Copy link

3nrique0 commented Feb 4, 2025

Describe the issue

I followed the instructions of mamba to make the installation.

Since the current "latest" install is not working I used the recommended solution, install from the version 24.11.2-1 as suggested in the corresponding issue: conda-forge/miniforge#716

I required to use the fullpath to launch mamba install:
$ ./miniforge3/bin/mamba create -n harpy -c bioconda -c conda-forge harpy

I tried different versions of mamba and conda and the result was consistently the same:
Incompatibility of packages

Harpy Version

1.16.3

File triggering the error (if applicable)

No response

Harpy error log

$ ./miniforge3/bin/mamba create -n harpy -c bioconda -c conda-forge harpy

Could not solve for environment specs
The following packages are incompatible
└─ harpy is not installable because there are no viable options
   ├─ harpy [0.1.1|0.2.0|0.3.0|0.4.0] would require
   │  └─ r-magrittr but there are no viable options
   │     ├─ r-magrittr 1.5 would require
   │     │  └─ r 3.2.2* , which does not exist (perhaps a missing channel);
   │     ├─ r-magrittr 1.5 would require
   │     │  └─ r 3.3.1* , which does not exist (perhaps a missing channel);
   │     └─ r-magrittr [1.5|2.0.1|2.0.2|2.0.3] conflicts with any installable versions previously reported;
   ├─ harpy [0.5.0|0.6.0|...|1.9] would require
   │  ├─ bcftools 1.19.* , which requires
   │  │  └─ htslib [>=1.19,<1.22.0a0 |>=1.19.1,<1.22.0a0 ] but there are no viable options
   │  │     ├─ htslib [1.20|1.21] would require
   │  │     │  └─ libdeflate >=1.20,<1.24.0a0 , which conflicts with any installable versions previously reported;
   │  │     ├─ htslib [1.19|1.19.1|1.20] would require
   │  │     │  └─ libdeflate >=1.18,<1.24.0a0 , which conflicts with any installable versions previously reported;
   │  │     └─ htslib 1.21 would require
   │  │        └─ libdeflate >=1.22,<1.24.0a0 , which conflicts with any installable versions previously reported;
   │  ├─ pysam 0.22.*  but there are no viable options
   │  │  ├─ pysam [0.22.0|0.22.1] would require
   │  │  │  └─ libdeflate >=1.18,<1.24.0a0 , which conflicts with any installable versions previously reported;
   │  │  ├─ pysam 0.22.1 would require
   │  │  │  └─ libdeflate >=1.22,<1.24.0a0 , which conflicts with any installable versions previously reported;
   │  │  └─ pysam 0.22.1 would require
   │  │     └─ libdeflate >=1.20,<1.24.0a0 , which conflicts with any installable versions previously reported;
   │  └─ samtools 1.20.* , which requires
   │     └─ htslib >=1.20,<1.22.0a0 , which cannot be installed (as previously explained);
   └─ harpy [1.10|1.10.1|...|1.9] would require
      └─ conda >24.7 , which requires
         └─ boltons >=23.0.0 , which conflicts with any installable versions previously reported.
@3nrique0 3nrique0 added the bug Something isn't working label Feb 4, 2025
@pdimens
Copy link
Owner

pdimens commented Feb 4, 2025

Yikes. Try to put a version boundary on harpy, like harpy=1.16

@pdimens pdimens self-assigned this Feb 4, 2025
@pdimens
Copy link
Owner

pdimens commented Feb 6, 2025

@3nrique0 have you made progress on this?

@3nrique0
Copy link
Author

Hello,

Not at all, I tried it with harpy=1.16 and 1.15 and the error was almost the same.
It was preceded by multiple lines of:
warning libmamba Problem type not implemented SOLVER_RULE_STRICT_REPO_PRIORITY

I re-installed miniforge in case that was the problem. But it remains.

I'm going to try again by downgrading the miniforge installation seen this error that seems related: conda-forge/miniforge#716

Then i'll try again pixi

@pdimens
Copy link
Owner

pdimens commented Feb 12, 2025

That's really unusual and I'm sorry that's happening. Can you get a local conda install, using prefix instead of name? Maybe the base environment is causing issues.

Otherwise, the pixi install should be pretty effortless, especially if doing a local install, since pixi doesn't rely on any base environments.

@3nrique0
Copy link
Author

Yes, I tried, It gave the same error as with the boundry:

Could not solve for environment specs The following package could not be installed └─ harpy 1.16** is not installable because it requires └─ conda >24.7 , which requires └─ boltons >=23.0.0 , which conflicts with any installable versions previously reported.

Switching to pixi

@3nrique0
Copy link
Author

Well.. it turned on the pixi shell and it was able to open it in the Scheduler (slurm). But there was the same error in the slurm out. The error was the same with the incompatibility of packages.

slurm-15460502.txt

I'll try a different cluster

@pdimens
Copy link
Owner

pdimens commented Feb 12, 2025

This issue seems specific to the cluster/system you are working on. If you haven't already, I would recommend you reach out to the admins of your system, as I suspect there is something about the configuration that is causing these issues.

Looking at the log file, the issues with installing dependencies is confusing because all the requisite packages are available via bioconda and conda-forge, which are specified in the environment yaml definition file. This then perhaps suggest that it's a python versioning issue, however the log indicates that it tries installing python 3.12, which would be fine. Your sys admins might know why the conda solver is failing/struggling to find the appropriate software from these (correct and declared) channels.

You can also try to use --container to have snakemake pull the premade harpy Singularity container instead of creating conda environments, however our team has seen mixed results with that depending on different advanced cluster contexts (network FS, etc.). I suppose there's no harm in trying that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants