Closed IndigoWizard closed 1 month ago
The following is the full log of the same work session from creating the env to testing mamba:
I tried updating mamba but the error persisted:
I tried removing mamba package and reinstalling it:
An anterior version of mamba is installed (mamba 0.15.3
) instead of the latest update (mamba 0.24.0
) as when mamba was first installed before installing geopandas
.
I decide to try and update the mamba 0.15.3
to the latest version mamba 0.24.0
after it installed and worked:
I faced the same issue when I tried to build a conda package using "boa"
The command was: conda mambabuild ./conda.recipe/ --output-folder /tmp/__localbuild__/conda/ --no-test -q
The error:
Traceback (most recent call last):
File "/tmp/conda_envs/py37-conda-build/bin/conda-mambabuild", line 6, in <module>
from boa.cli.mambabuild import main
File "/tmp/conda_envs/py37-conda-build/lib/python3.7/site-packages/boa/cli/mambabuild.py", line 21, in <module>
from boa.core.solver import MambaSolver
File "/tmp/conda_envs/py37-conda-build/lib/python3.7/site-packages/boa/core/solver.py", line 21, in <module>
import libmambapy
File "/tmp/conda_envs/py37-conda-build/lib/python3.7/site-packages/libmambapy/__init__.py", line 7, in <module>
raise e
File "/tmp/conda_envs/py37-conda-build/lib/python3.7/site-packages/libmambapy/__init__.py", line 4, in <module>
from libmambapy.bindings import * # noqa: F401,F403
ImportError: libarchive.so.13: cannot open shared object file: No such file or directory
I compare a healthy environment with the unhealthy environment and there are 3 diffs: healthy vs unhealthy libarchive 3.5.2 hb890918_2 vs libarchive 3.5.2 h5de8990_0 lzo 2.10 vs None tk 8.6.11 h1ccaba5_1 vs tk 8.6.12 h1ccaba5_0
I suspect that somehow the libarchive was corrupted by someone...
As a workaround, the following command solved the issue:
mamba install libarchive=3.5.2=hb890918_2 -y
I also experienced the same ImportError: libarchive.so.13: cannot open shared object file: No such file or directory
problem.
libarchive
from defaults
channel seems broken but the one from conda-forge
is working.
So this install line resulted in a broken mamba for me: conda install mamba -n base -c defaults -c conda-forge
.
But this install line worked (switched channels priority order): conda install mamba -n base -c conda-forge -c defaults
.
The side-effect is the entire base
env is now updated to conda-forge version. Hope there is no negative effect.
I am currently seeing this issue with both the conda-forge and defaults channel. Running mamba install libarchive=3.5.2=hb890918_2 -y
also results in the same error for me. Anyone got any suggestions?
Had the same problem, which I think came from an inconsistent version of libmambapy. Remove it, if you do not explicitly need it. Worked fine for me.
To be more exact: I had an older version (0.24) in the current environment (relict from some test some time ago), while the base env was already at 0.27.
ImportError: DLL load failed while importing mamba_api: The specified module could not be found.
tried uninstalling and installing
I met the same error:
> mamba
Traceback (most recent call last):
File "D:\miniforge3\Scripts\mamba-script.py", line 6, in <module>
from mamba.mamba import main
File "D:\miniforge3\lib\site-packages\mamba\mamba.py", line 49, in <module>
import libmambapy as api
File "D:\miniforge3\lib\site-packages\libmambapy\__init__.py", line 7, in <module>
raise e
File "D:\miniforge3\lib\site-packages\libmambapy\__init__.py", line 4, in <module>
from libmambapy.bindings import * # noqa: F401,F403
ImportError: DLL load failed while importing bindings: ๆพไธๅฐๆๅฎ็ๆจกๅใ
> conda list mamba
# packages in environment at D:\miniforge3:
#
# Name Version Build Channel
libmamba 1.1.0 ha1e45d8_2 conda-forge
libmambapy 1.1.0 py310h954024b_2 conda-forge
mamba 1.1.0 py310h9376f3e_2 conda-forge
I use Dependencies to look at D:\miniforge3\Lib\site-packages\libmambapy\bindings.cp310-win_amd64.pyd
and there is a missing DLL ext-ms-win-oobe-query-l1-1-0.dll
I[m having the libarchive error as well
While not a solution to this problem, maybe a cure: Try using micromamba.
I'm also having this error
Hi everyone, please stop adding new comments that donโt provide any new insights other than youโre also affected. Comments will notify everyone in this thread. Please use emoji reactions instead.
I just installed mambaforge (comes with mamba 1.1.0) on a Windows 10 machine. Everything was going fine installing the packages I need until I used mamba to install the vtk library. Then I got this exact error. With mamba broken and no conda to back it up, I had to uninstall.
I don't know what about vtk or its dependencies could have broken mamba, but hopefully this will provide a clue of some sort?
On my second try with mambaforge, the first thing I did right after installing the Windows executable was to update mamba to 1.3.1. The second thing I did was try to install vtk (mamba install vtk). That breaks it.
Please open a new issue with exact steps how to reproduce, thanks!
I recognized that I can repare a broken env by any existing env
conda activte ENV_IN_GOOD_STATE
c:/Users/r.bauer/Miniconda3/envs/mssenv/Scripts/conda.exe install -p C:\Users\r.bauer\Miniconda3\envs\ENV_TO_REPAIR python conda==22.9.0
Note that Conda should not be installed to environments other than base though. See https://mamba.readthedocs.io/en/latest/user_guide/troubleshooting.html#mamba-should-be-installed-to-the-base-environment
I had the same issue with a self-hosted CI using setup-miniconda with mamba. The github runner is running in a container defined by this dockerfile: https://github.com/osl-incubator/github-actions-self-hosted-runner/blob/main/Dockerfile
for the record, it is the setup-miniconda configuration I am using:
- uses: conda-incubator/setup-miniconda@v2
with:
miniconda-version: "latest"
mamba-version: "1.*"
environment-file: conda/release.yaml
channels: nodefaults,conda-forge
channel-priority: true
activate-environment: release
miniforge-variant: Mambaforge
and this is the log from the CI runner: https://pastebin.com/9kzyBsC8
maybe the problem is in the setup-miniconda side .. not sure .. but I am sharing it here in the case the logs could help in the discussion.
Consider switching to https://github.com/mamba-org/setup-micromamba
thanks @jonashaag ! I will give a shot :) appreciate your recommendation!
Installing mamba 1.4.6, 1.4.7 or 1.4.9 directly triggered the same libarchive.so.13
error for me.
However, somehow for me it seems to be working after installing mamba 1.4.5, and then updating to 1.4.9.
conda install 'mamba<=1.4.5' -n base -c conda-forge
conda update mamba -n base -c conda-forge
# At first: conda-forge/linux-64::mamba-1.4.5-py311h3072747_0
# Then: 1.4.5-py311h3072747_0 --> 1.4.9-py311h3072747_0
When you have a recent conda by anaconda, then you have the libmamba solver builtin. https://www.anaconda.com/blog/a-faster-conda-for-a-growing-community
If you don't use anaconda's default channel but have conda-forge your first or only channel have a look on mambaforge.
On conda-forge, libmamba
explicitly depends on libarchive
.
libarchive
correctly packages its dynamic library file: this is checked by the tests on the feedstock and one can verify by uncompressing packages.
The problem is likely due to mixing channels (e.g. defaults
used by miniconda
and conda-forge
used by subsequent CLI calls), with libarchive
being packaged differently on both channels.
To prevent such problems, we recommend against mixing channels generally; hence only use:
defaults
if you use setup-miniconda
and miniconda
conda-forge
if you use setup-micromamba
and miniforge
.For now, I will close this issue. If someone observes the problem again, I would recommend that they provide a reproducer here.
Main issue gist
Mamba stops working after installing geopandas (installing geopandas successfully using mamba itself).
How/what went wrong:
Trying to install
geospatial
, following basic steps in documentation:Main error:
Happens when executing any mamba commend, demonstrated here through
mamba list
. (error message is in french but it's what the issue title says)Additional info:
I already faced this very issue the day before, following the same procedure. In this session, I tried to start again from scratch, cleaned up the mess (deleted previous env), started new env and followed same steps and got the same error.