-
Notifications
You must be signed in to change notification settings - Fork 359
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
Environment creation fails in mamba and micromamba if it contains the _x86_64-microarch-level package in Linux #3222
Comments
I noticed that |
I've found that my environments that require a
will fail with
in fact, even after activating the environment, mamba will not recognize that one could "update" to the 100s level package to install .
|
Sorry for the noise on your issue. I think the problem with my issue is that mamba uses nvidia-smi to detect the cuda version:
whereas conda uses heuristics based on typical installation paths: I was able to install nvidia-smi to resolve my issue with the I suspect there are other quirks with how virtual packages are detected for bleeding edge features. Maybe conda + libmamba is enough to help you! So I tracked it down to a change between mamba version 1.4.5 and 1.4.6 On 1.4.5 base environment
Environment resolution with the command
succeeds with:
Then updating mamba to 1.4.6 and running the same command:
|
Sorry @hmaarrfk, I had missed your comment. Yes, the problem are similar but different, they boil down to virtual packages to be implemented in different ways in conda and mamba (and also rattler/pixi), so these issues emerge. Indeed the long term solution is for users to use either conda or rattler/pixi, so we reduce the number of different virtual packages implementations from 3 to 2, but users tend to me lazy in change tools (especially when muscle memory of commands to type is involved). The main problem here is that in the context of conda-forge/conda-forge.github.io#1261 if you try to add archspec support as documented (as of May 2024) in https://conda-forge.org/docs/maintainer/knowledge_base/#microarch, this will result in packages that silently can't be installed at all with mamba, that may be an issue difficult to debug. Probably a possible strategy is to remove the |
I just tested with mamba 2 and the problem is still present. As more packages are added to conda-forge that use archspec-optimized builds as described in https://conda-forge.org/docs/maintainer/knowledge_base/#microarch, all such builds (even the one with microarch_level==1) can't be installed with mamba, resulting in mamba silently installing old version of the packages that are not archspec-optimized. For example, trying to install the latest version of the conda:
mamba:
|
By looking a bit more into this, the problems seems that mamba reports generic microarch as mamba/libmamba/src/core/virtual_packages.cpp Lines 177 to 191 in 83fdeae
x86_64_v3 , see https://github.com/conda-forge/microarch-level-feedstock/blob/1b446dbab3999c5e27f1e0b000231f18fa1b6df1/recipe/conda_build_config.yaml#L15 .
Probably it make sense to open a sister issue in https://github.com/conda-forge/microarch-level-feedstock to let the maintainers there be aware of this. |
Yeah we should fix it to report |
Thanks, done in #3404 . |
Fix x86_64 to use underscore instead of dash See #3222 (comment) .
See #3222 (comment) . Co-authored-by: Julien Jerphanion <[email protected]>
Troubleshooting docs
Anaconda default channels
How did you install Mamba?
Mambaforge or latest Miniforge
Search tried in issue tracker
archspec
Latest version of Mamba
Tried in Conda?
I do not have this problem with Conda, just with Mamba
Describe your issue
If I try to run
mamba -v create -n test _x86_64-microarch-level
ormicromamba -v create -n test _x86_64-microarch-level
, the environment creation fails. If I tryconda create -n test _x86_64-microarch-level
or install the_x86_64-microarch-level
package in pixi, the installation in successful.Related to conda-forge/staged-recipes#24306 and conda-forge/conda-forge.github.io#2091 .
mamba info / micromamba info
Logs
environment.yml
~/.condarc
The text was updated successfully, but these errors were encountered: