Closed manopapad closed 1 month ago
mbargull
commented
11 months ago Issue with conda=23.11, see https://github.com/conda/conda/issues/13400#issue-2025834712 .
You can install conda install conda=23.10 for now to get things working again.
jezdez
commented
11 months ago I can't find the source of where the Currently, only install, create, list, search, run, info, clean, remove, update, repoquery, activate and deactivate are supported through mamba. comes from, can anyone point me to that?
jaimergp
commented
11 months ago 
image80
commented
11 months ago Hello, on my side, i have exactly the same error message with conda 23.10.0 and python 3.11.5. I paste below my test :
(iota2-env) XXXXXXXX@XXXXXXXX:~$ mamba install iota2 -c iota2 -c iota2-deps
Currently, only install, create, list, search, run, info, clean, remove, update, repoquery, activate and deactivate are supported through mamba.If needed, i paste below the result of conda info command :
(iota2-env) xxxxxxe@xxxxx:~$ conda info
active environment : iota2-env
active env location : /home/geomatique/miniconda3/envs/iota2-env shell level : 2
user config file : /home/geomatique/.condarc
populated config files : /home/geomatique/.condarc
conda version : 23.10.0
conda-build version : not installed
python version : 3.11.5.final.0
virtual packages : __archspec=1=cascadelake
__cuda=12.2=0
__glibc=2.35=0
__linux=5.15.133.1=0
__unix=0=0
base environment : /home/geomatique/miniconda3 (writable)
conda av data dir : /home/geomatique/miniconda3/etc/conda
conda av metadata url : None
channel URLs : https://conda.anaconda.org/iota2/linux-64
https://conda.anaconda.org/iota2/noarch
https://conda.anaconda.org/pytorch/linux-64
https://conda.anaconda.org/pytorch/noarch
https://conda.anaconda.org/conda-forge/linux-64
https://conda.anaconda.org/conda-forge/noarch
https://repo.anaconda.com/pkgs/main/linux-64
https://repo.anaconda.com/pkgs/main/noarch https://repo.anaconda.com/pkgs/r/linux-64
https://repo.anaconda.com/pkgs/r/noarch
package cache : /home/geomatique/miniconda3/pkgs
/home/geomatique/.conda/pkgs
envs directories : /home/geomatique/miniconda3/envs
/home/geomatique/.conda/envs
platform : linux-64
user-agent : conda/23.10.0 requests/2.31.0 CPython/3.11.5 Linux/5.15.133.1-microsoft-standard-WSL2 ubuntu/22.04.3 glibc/2.35 solver/libmamba conda-libmamba-solver/23.11.1 libmambapy/1.5.3
UID:GID : 1000:1000
netrc file : None
offline mode : FalseThanks so much for your help
jezdez
commented
11 months ago This is likely triggered by https://github.com/conda/conda/pull/13173 that makes the code in mamba 1.x use a full import path instead of a relative one.
image80
commented
11 months ago Thank you @jezdez for your message. Do you know how to fix this issue? Should i downgrage/install another/old version of conda ? On another ubuntu computer (with version conda 23.5.2), i did not get this mamba issue. Thank so much.
jezdez
commented
11 months ago @image80 Downgrading is the best course of action until we have a proper fix out.
jezdez
commented
11 months ago Yeah, I believe https://github.com/conda/conda/pull/13173 changes the CLI parsing so that the argparse callback function path is stored as an absolute path and not relative anymore, which is bubbled up in mamba CLI as an error, seemingly not having any subcommand available. I would call that an unfortunate compatibility bug, if it wouldn't affect so many users automatically on upgrading conda in conda-forge.
Since this is easy to fix in a backward-compatible way, I would err on fixing mamba instead of rolling back the change in conda. Personally, I consider the change in conda to be acceptable and not needing to be covered by the deprecation policy per CEP 9.
But obviously, it's unfortunate that this wasn't caught by a CI system ahead of time. We shall improve that by more conservative version pinning of the conda dependency in mamba, or running mamba tests as part of the conda release, as suggested by @SylvainCorlay to me.
jezdez
commented
11 months ago I proposed patch for mamba CLI is here: https://github.com/mamba-org/mamba/pull/3036
mbargull
commented
11 months ago But obviously, it's unfortunate that this wasn't caught by a CI system ahead of time. We shall improve that by more conservative version pinning of the conda dependency in mamba, or running mamba tests as part of the conda release, as suggested by @SylvainCorlay to me.
Yes, for packages that have a higher impact on the ecosystem, it would be reasonable to run a (small) selection of tests upstream.
Additionally, it would make sense for mamba -- at least as long as it is tightly integrated with conda's code -- to add some additional tests for pre-releases; e.g., conda-build runs tests against the conda-canary/label/dev channel: https://github.com/conda/conda-build/blob/3.28.0/.github/workflows/tests.yml#L85 .
SylvainCorlay
commented
11 months ago @JohanMabille Since conda 23.11.0 requires conda-libmamba-solver >=23.11.0, which requires libmamba >=1.5.3, only mamba 1.5.3 is affected by this breakage, so we should be able to make a patch release, and a repodata patch forcing 1.5.3 to be installed with conda<3.11...
To the more general point of preventing this kind of breakage, mamba and conda are both upstream to each other in a way (since conda depends on libmamba, and mamba depends on the conda CLI). It makes sense to be a bit cautious about all of this. Some CI set up could be a way to go. Note that mamba 2.0 will not depend on conda at all, which will make the situation a bit simpler.
mbargull
commented
11 months ago repodata patch forcing 1.5.3 to be installed with conda<3.11...
We already put in a repodata patch on conda-forge for this.
I just checked if it works as intended an indeed an create conda=23.11 mamba prevents the env creation as intended.
... But mamba install conda=23.11 and CONDA_SOLVER=libmamba conda install conda=23.11 into an environment with mamba already installed still succeeds (leaving mamba non-functional afterwards). (Could be something with preferring dependency info from installed packages over conflicting ones coming from the channel?)
So, we probably need better/additional fixes (possibly/hopefully with a newer mamba version it will just install that).
JohanMabille
commented
11 months ago I've just released 1.5.4, working on the feedstock now, it should be available on conda-forge in the next couple of hours.
jezdez
commented
11 months ago I've just released 1.5.4, working on the feedstock now, it should be available on conda-forge in the next couple of hours.
Thank you so much!
@SylvainCorlay
To the more general point of preventing this kind of breakage, mamba and conda are both upstream to each other in a way (since conda depends on libmamba, and mamba depends on the conda CLI). It makes sense to be a bit cautious about all of this. Some CI set up could be a way to go.
I can't say I've run the mamba 1.x tests before locally recently, maybe it'd be worth running them (or a subset) in the conda conda-forge feedstock upon release?
jaimergp
commented
11 months ago I can't say I've run the mamba 1.x tests before locally recently, maybe it'd be worth running them (or a subset) in the conda conda-forge feedstock upon release?
Maybe it's just a matter of a little smoke tests in the conda recipe. Adding mamba to the test.requires and then having test.commands include mamba create --dry-run -n unused flask. Even better if we do that in the conda canary so we don't learn about it too late in the release process.
xylar
commented
11 months ago Yes, please, please, please do add a mamba test to the conda feedstock. These kinds of breaking changes can be really disruptive. I would be willing to help but it would be better if it's done by the experts.
jaimergp
commented
11 months ago See also #3029
mbargull
commented
11 months ago Yes, please, please, please do add a
mambatest to thecondafeedstock.
We can add a downstreams test to conda-feedstock, yes.
That being said, those tests should really already happen before we hit the packaging phase.
(Even though we obviously have a large overlap between devs of the tools and package maintainers, we should still differentiate those roles.)
These kinds of breaking changes can be really disruptive.
To be clear, any release of conda could render mamba non-functional since there is no well-defined interface between the code bases of both projects.
Meaning, "these kinds of breaking changes" are fine to happen if conda internals are being worked on -- we (as maintainers of the ecosystem) just must be made aware of incompatibilities somehow. Regular testing (on multiple fronts) would help us (and with us I mean any of us, not "taking sides"; thinking of "sides" on these issues would be futile...).
JohanMabille
commented
11 months ago Yes, please, please, please do add a
mambatest to thecondafeedstock. These kinds of breaking changes can be really disruptive. I would be willing to help but it would be better if it's done by the experts.
We also set a more restrictive upper bound on conda in the mamba feedstock, so that when a new conda release is cut, we can test whether mamba is broken, fix it if needed, and relax the constraint without breaking the ecosystem.
mbargull
commented
11 months ago repodata patch forcing 1.5.3 to be installed with conda<3.11...
We already put in a repodata patch on conda-forge for this. I just checked if it works as intended an indeed an
create conda=23.11 mambaprevents the env creation as intended. ... Butmamba install conda=23.11andCONDA_SOLVER=libmamba conda install conda=23.11into an environment withmambaalready installed still succeeds (leavingmambanon-functional afterwards). (Could be something with preferring dependency info from installed packages over conflicting ones coming from the channel?) So, we probably need better/additional fixes (possibly/hopefully with a newermambaversion it will just install that).
To follow up:
conda-forge::mamba=1.5.4 is now up.
With that, CONDA_SOLVER=libmamba conda update conda/mamba update conda still won't touch mamba=1.5.3 and install conda=23.11.0 alongside it, which will render mamba non-functional again.
Adding insult to injury: CONDA_SOLVER=libmamba conda update mamba/mamba update mamba for me updates a conda=23.10.0 to conda=23.11.0 while actually leaving mamba=1.5.3 untouched again, leading us to the same unwanted outcome. :unamused:
JohanMabille
commented
11 months ago If I understand correctly, before you try to update anything you have mamba=1.5.3 and conda=23.10.0 installed, correct?
Can you try the following and let me know if it works?
$PREFIX/pkgs/libmamba-1.5.3-*, $PREFIX/pkgs/libmambapy-1.5.3-* and $PREFIX/pkgs/mamba-1.5.4-*CONDA_SOLVER=libmamba conda update mambaIf that does not work (do not restore the previously removed files yet):
CONDA_SOLVER=libmamba conda install mamba=1.5.2CONDA_SOLVER=libmamba mamba update mambaEDIT: my assumption is that your install is using the mamba 1.5.3 cache you have, with the wrong dependencies, instead of downloading it with the patched repodata entry (but I don't understand why mamba upgrade mamba does not install mamba 1.5.4 in your case). I just tried the following:
mamba 1.4.9 and conda 23.5.0mamba=1.5.3 and conda 23.10.0mamba update mambaThe last command successfully upgraded to mamba 1.5.4 and conda 23.11.0
mbargull
commented
11 months ago Oh, sorry, I have to correct myself:
mamba update mamba is the only one that does work (i.e., updates to mamba=1.5.4).
But all the others (mamba update conda, CONDA_SOLVER=libmamba conda update conda, CONDA_SOLVER=libmamba conda update mamba) do not work.
I'm working off of the current quay.io/condaforge/linux-anvil-cos7-x86_64:latest, i.e., it should be easy to reproduce.
Yes, this has mamba=1.5.3 with the unpatched dependencies installed.
The contents of CONDA_PKGS_DIRS should not matter.
But I guess you actually mean the environments metadata, i.e., ${CONDA_PREFIX}/conda-meta/mamba-1.5.3-*.json.
Yes, if that one is changed, the behavior differs, of course.
This was also what I hinted at https://github.com/mamba-org/mamba/issues/3033#issuecomment-1840774262 with
(Could be something with preferring dependency info from installed packages over conflicting ones coming from the channel?)
(To be fair: Disagreements between repodata.json and the environment's data are tricky to handle (as in sometimes these lead to unresolvable states) since hacking on repodata isn't a thing that was conceptually considered way back when...)
sweettyler
commented
11 months ago On Linux, after upgrading mamba from 1.5.3 to 1.5.4, "mamba update --all" worked again, but "mamba clean --yes --all" still had an error similar to what reported in #534.
mbargull
commented
11 months ago On Linux, after upgrading mamba from 1.5.3 to 1.5.4, "mamba update --all" worked again, but "mamba clean --yes --all" still had an error similar to what reported in #534.
Thanks for the report!
mamba clean has the same import_module("conda.cli" + ...) pattern, but at a separate place such that it was not covered with the fix from gh-3036.
I mechanically copied @jezdez's fix over in gh-3040 and it seems to do the trick.
JohanMabille
commented
11 months ago The contents of CONDA_PKGS_DIRS should not matter. But I guess you actually mean the environments metadata, i.e., ${CONDA_PREFIX}/conda-meta/mamba-1.5.3-*.json.
I really meant the content of CONDA_PKGS_DIRS, there is a repodata_record.json and an index.json file contianing the dependencies, and I think that mamba is using one of them when installing the package (but I'm really not sure of that, I need to check again, this always confuses me). Cleaning this folder sometimes helps in solving resolution / install problems, so I think it's not neutral.
But all the others (mamba update conda, CONDA_SOLVER=libmamba conda update conda, CONDA_SOLVER=libmamba conda update mamba) do not work.
I wonder if rebuilding conda-libmamba-solver could help. It depends on libmambapy>=1.5.3 which as a run_export pinning max(x.x) so maybe if we rebuild conda-libmamba-solver against libmambapy==1.5.4, it should generate a dependency on libmambapy>=1.5.4,<1.6 ? Or does it consider the dependency constraint from conda-libmamba-solver higher priority or does it choose the least restrictive constraint?
mbargull
commented
11 months ago I really meant the content of
CONDA_PKGS_DIRS, there is arepodata_record.jsonand anindex.jsonfile contianing the dependencies, and I think that mamba is using one of them when installing the package (but I'm really not sure of that, I need to check again, this always confuses me). Cleaning this folder sometimes helps in solving resolution / install problems, so I think it's not neutral.
I can't see why...
Nonetheless:
Which shows that if the entry in conda-meta is updated (here by removing mamba=1.5.3 from the prefix at some point).
You could achieve the same if you manually edit conda-meta/mamba-1.5.3-*.json.
Or by removing/installing it:
As said, this is all in containers from the current quay.io/condaforge/linux-anvil-cos7-x86_64:latest image; you can test it out with that easily.
jaimergp
commented
11 months ago Hey folks, sorry for the brevity as I type this afk.
IIUC, this has to do with the history blocking the update. The usual workaround is to enumerate all the packages that should be updated:
conda update conda mamba conda-libmamba-solverconda update --all might also work (but too much maybe?), or even --update-specs. I think --prune will let conda know to ignore the history but I am not sure if that flag is enabled in all commands. CONDA_PRUNE=1 might work instead.
Let me know if that helps. There's a rationale behind this that I'd be happy to discuss too, but it's a bit tricky to type all of that on the phone.
jdblischak
commented
11 months ago But obviously, it's unfortunate that this wasn't caught by a CI system ahead of time.
Additionally, it would make sense for mamba -- at least as long as it is tightly integrated with conda's code -- to add some additional tests for pre-releases; e.g., conda-build runs tests against the conda-canary/label/dev channel
Some CI set up could be a way to go.
tl;dr Such a CI pipeline already exists, but it requires more attention when it fails
To clarify, the mamba repository already has a CI pipeline to test against conda from the conda-canary channel. It runs every Sunday
https://github.com/mamba-org/mamba/blob/main/.github/workflows/conda_canary.yml
It opens an Issue if it fails, and it has been failing for weeks for unrelated reasons
https://github.com/mamba-org/mamba/issues?q=is%3Aissue+Bot+failure+
Unfortunately the PR to fix the scheduled canary build (https://github.com/mamba-org/mamba/pull/2950) wasn't merged prior to the release of conda 23.11.0. The CI run on this PR actually caught this compatibility error: https://github.com/mamba-org/mamba/issues/3029#issuecomment-1841495326
Now that the CI fix has been merged, the canary CI is passing again, I assume thanks to the recently merged PR https://github.com/mamba-org/mamba/pull/3040
https://github.com/mamba-org/mamba/actions/runs/7114168786
Thus in order to catch these types of compatibility errors prior to the next release, we don't necessarily need more CI infrastructure (though more is always better), but we do need to better monitor and address the Issues that are auto-opened when a canary CI run fails
beckermr
commented
11 months ago I just want to comment that it cannot possibly be correct behavior for “mamba update —all” to make updates to the packages that violate constraints from the downloaded repodata.
LiutongZhou
commented
10 months ago mamba repoquery search not working. Mamba version 1.5.6. Conda version 23.11.0. Python 3.11
mamba repoquery search python
Currently, only install, create, list, search, run, info, clean, remove, update, repoquery, activate and deactivate are supported through mamba.I also found this and finally decided to start over with a fresh Miniforge and stop using the mamba commands at all. The conda commands seem to be just as fast with the libmamba solver installed.
JohanMabille
commented
10 months ago mamba repoquery search not working. Mamba version 1.5.6. Conda version 23.11.0
mamba repoquery search python Currently, only install, create, list, search, run, info, clean, remove, update, repoquery, activate and deactivate are supported through mamba.
Can you post the result of mamba list please? mamba repoquery works like a charm for me with the following (including mamba 1.5.6 and conda 23.11.0):
# Name Version Build Channel
_libgcc_mutex 0.1 conda_forge conda-forge2
_openmp_mutex 4.5 2_gnu conda-forge2
archspec 0.2.2 pyhd8ed1ab_0 conda-forge2
boltons 23.0.0 pyhd8ed1ab_0 conda-forge2
brotli-python 1.0.9 py310hd8f1fbe_9 conda-forge2
brotlipy 0.7.0 py310h5764c6d_1005 conda-forge2
bzip2 1.0.8 h7f98852_4 conda-forge2
c-ares 1.24.0 hd590300_0 conda-forge2
ca-certificates 2023.11.17 hbcca054_0 conda-forge2
certifi 2023.11.17 pyhd8ed1ab_0 conda-forge2
cffi 1.15.1 py310h255011f_3 conda-forge2
charset-normalizer 3.2.0 pyhd8ed1ab_0 conda-forge2
colorama 0.4.6 pyhd8ed1ab_0 conda-forge2
conda 23.11.0 py310hff52083_1 conda-forge2
conda-libmamba-solver 23.12.0 pyhd8ed1ab_0 conda-forge2
conda-package-handling 2.2.0 pyh38be061_0 conda-forge2
conda-package-streaming 0.9.0 pyhd8ed1ab_0 conda-forge2
cryptography 41.0.2 py310h75e40e8_0 conda-forge2
distro 1.9.0 pyhd8ed1ab_0 conda-forge2
fmt 10.1.1 h00ab1b0_1 conda-forge2
icu 72.1 hcb278e6_0 conda-forge2
idna 3.4 pyhd8ed1ab_0 conda-forge2
jsonpatch 1.32 pyhd8ed1ab_0 conda-forge2
jsonpointer 2.0 py_0 conda-forge2
keyutils 1.6.1 h166bdaf_0 conda-forge2
krb5 1.21.2 h659d440_0 conda-forge2
ld_impl_linux-64 2.40 h41732ed_0 conda-forge2
libarchive 3.7.2 h039dbb9_0 conda-forge2
libcurl 8.5.0 hca28451_0 conda-forge2
libedit 3.1.20191231 he28a2e2_2 conda-forge2
libev 4.33 h516909a_1 conda-forge2
libffi 3.4.2 h7f98852_5 conda-forge2
libgcc-ng 13.1.0 he5830b7_0 conda-forge2
libgomp 13.1.0 he5830b7_0 conda-forge2
libiconv 1.17 h166bdaf_0 conda-forge2
libmamba 1.5.6 had39da4_0 conda-forge2
libmambapy 1.5.6 py310h39ff949_0 conda-forge2
libnghttp2 1.58.0 h47da74e_1 conda-forge2
libnsl 2.0.0 h7f98852_0 conda-forge2
libsolv 0.7.24 hfc55251_1 conda-forge2
libsqlite 3.42.0 h2797004_0 conda-forge2
libssh2 1.11.0 h0841786_0 conda-forge2
libstdcxx-ng 13.1.0 hfd8a6a1_0 conda-forge2
libuuid 2.38.1 h0b41bf4_0 conda-forge2
libxml2 2.11.5 h0d562d8_0 conda-forge2
libzlib 1.2.13 hd590300_5 conda-forge2
lz4-c 1.9.4 hcb278e6_0 conda-forge2
lzo 2.10 h516909a_1000 conda-forge2
mamba 1.5.6 py310h51d5547_0 conda-forge2
menuinst 2.0.1 py310hff52083_0 conda-forge2
ncurses 6.4 hcb278e6_0 conda-forge2
openssl 3.2.0 hd590300_1 conda-forge2
packaging 23.1 pyhd8ed1ab_0 conda-forge2
pip 23.1.2 pyhd8ed1ab_0 conda-forge2
platformdirs 4.1.0 pyhd8ed1ab_0 conda-forge2
pluggy 1.2.0 pyhd8ed1ab_0 conda-forge2
pybind11-abi 4 hd8ed1ab_3 conda-forge2
pycosat 0.6.4 py310h5764c6d_1 conda-forge2
pycparser 2.21 pyhd8ed1ab_0 conda-forge2
pyopenssl 23.2.0 pyhd8ed1ab_1 conda-forge2
pysocks 1.7.1 pyha2e5f31_6 conda-forge2
python 3.10.12 hd12c33a_0_cpython conda-forge2
python_abi 3.10 3_cp310 conda-forge2
readline 8.2 h8228510_1 conda-forge2
reproc 14.2.4 h0b41bf4_0 conda-forge2
reproc-cpp 14.2.4 hcb278e6_0 conda-forge2
requests 2.31.0 pyhd8ed1ab_0 conda-forge2
ruamel.yaml 0.17.32 py310h2372a71_0 conda-forge2
ruamel.yaml.clib 0.2.7 py310h1fa729e_1 conda-forge2
ruamel_yaml 0.15.80 py310h5764c6d_1008 conda-forge2
setuptools 68.0.0 pyhd8ed1ab_0 conda-forge2
tk 8.6.12 h27826a3_0 conda-forge2
toolz 0.12.0 pyhd8ed1ab_0 conda-forge2
tqdm 4.65.0 pyhd8ed1ab_1 conda-forge2
truststore 0.8.0 pyhd8ed1ab_0 conda-forge2
tzdata 2023c h71feb2d_0 conda-forge2
urllib3 2.0.3 pyhd8ed1ab_1 conda-forge2
wheel 0.40.0 pyhd8ed1ab_0 conda-forge2
xz 5.2.6 h166bdaf_0 conda-forge2
yaml 0.2.5 h7f98852_2 conda-forge2
yaml-cpp 0.8.0 h59595ed_0 conda-forge2
zstandard 0.22.0 py310h1275a96_0 conda-forge2
zstd 1.5.5 hfc55251_0 conda-forge2EDIT: don't pay attention to the conda-forge2 channel, it's just an alias to conda-forge
jaimergp
commented
10 months ago Is there a chance Python 3.11 is in use? xref https://github.com/conda/conda-libmamba-solver/issues/303 for context.
LiutongZhou
commented
10 months ago Can you post the result of
mamba listplease?mamba repoqueryworks like a charm for me with the following (including mamba 1.5.6 and conda 23.11.0):
I was using Python 3.11. I suspect it is Python 3.11 that has the problem.
Is there a chance Python 3.11 is in use? xref conda/conda-libmamba-solver#303 for context.
Yes. I was using Python 3.11.
Rolling back to Python 3.10 fixed the issue for me.
b-a0
commented
9 months ago Same issue: mamba 1.5.6 and conda 23.11.0
3.11 and 3.123.10mbargull
commented
9 months ago @LiutongZhou, @b-a0, could you provide information of you installations, i.e., the outputs of mamba info and conda config --show-sources?
b-a0
commented
9 months ago Sure, this is the output after downgrading my base environment to python 3.10.
mamba infoconda config --show-sourcesmbargull
commented
9 months ago Thanks, @b-a0. I could reproduce this at https://github.com/conda-forge/mamba-feedstock/pull/208#issuecomment-1923589700 . The failing command does not emit a non-zero exit code which is why this slipped through our tests...
mbargull
commented
9 months ago Should be fixed by gh-3170 once we have those changes released.
sangheonhan
commented
9 months ago Issue with
conda=23.11, see conda/conda#13400 (comment) . You can installconda install conda=23.10for now to get things working again.
After lowering conda to 23.10 with this method, everything is updating normally again.
Thank you.
acampove
commented
1 month ago It's been almost a year, is this still broken?
jjerphan
commented
1 month ago I cannot reproduce this issue with mamba 1.5.10, hence closing it as resolved accordingly.
Feel free to comment with a reproducer if you meet the problem again in the future.
Troubleshooting docs
Anaconda default channels
How did you install Mamba?
Mambaforge or latest Miniforge
Search tried in issue tracker
is:issue is:open 1.5.3
Latest version of Mamba
Tried in Conda?
I do not have this problem with Conda, just with Mamba
Describe your issue
Mamba 1.5.3 refuses to run any command. It always fails with "Currently, only install, create, list, search, run, info, clean, remove, update, repoquery, activate and deactivate are supported through mamba."
In the following output, I do the following:
mamba infoin the base environment, works as expectedmambaon the base environment to latest (1.5.3)mamba info, now it fails with "Currently, only install, create, list, search, run, info, clean, remove, update, repoquery, activate and deactivate are supported through mamba."Not showing in the output, but downgrading to 1.5.2 makes
mambawork again. Then mysteriously upgrading to 1.5.3 again works.Output
``` (base) iblis:~/quickstart> docker run -it --rm --gpus all ubuntu root@f9b94fb28d89:/# apt update Get:1 http://archive.ubuntu.com/ubuntu jammy InRelease [270 kB] Get:2 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB] Get:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [119 kB] Get:4 http://archive.ubuntu.com/ubuntu jammy-backports InRelease [109 kB] Get:5 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages [1792 kB] Get:6 http://archive.ubuntu.com/ubuntu jammy/multiverse amd64 Packages [266 kB] Get:7 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages [17.5 MB] Get:8 http://security.ubuntu.com/ubuntu jammy-security/universe amd64 Packages [1030 kB] Get:9 http://archive.ubuntu.com/ubuntu jammy/restricted amd64 Packages [164 kB] Get:10 http://archive.ubuntu.com/ubuntu jammy-updates/multiverse amd64 Packages [49.8 kB] Get:11 http://archive.ubuntu.com/ubuntu jammy-updates/restricted amd64 Packages [1520 kB] Get:12 http://archive.ubuntu.com/ubuntu jammy-updates/universe amd64 Packages [1298 kB] Get:13 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages [1535 kB] Get:14 http://archive.ubuntu.com/ubuntu jammy-backports/universe amd64 Packages [32.6 kB] Get:15 http://archive.ubuntu.com/ubuntu jammy-backports/main amd64 Packages [78.3 kB] Get:16 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages [1265 kB] Get:17 http://security.ubuntu.com/ubuntu jammy-security/restricted amd64 Packages [1494 kB] Get:18 http://security.ubuntu.com/ubuntu jammy-security/multiverse amd64 Packages [44.0 kB] Fetched 28.6 MB in 2s (13.6 MB/s) Reading package lists... Done Building dependency tree... Done Reading state information... Done 15 packages can be upgraded. Run 'apt list --upgradable' to see them. root@f9b94fb28d89:/# apt install wget Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: ca-certificates libpsl5 openssl publicsuffix The following NEW packages will be installed: ca-certificates libpsl5 openssl publicsuffix wget 0 upgraded, 5 newly installed, 0 to remove and 15 not upgraded. Need to get 1893 kB of archives. After this operation, 3944 kB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 openssl amd64 3.0.2-0ubuntu1.12 [1182 kB] Get:2 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 ca-certificates all 20230311ubuntu0.22.04.1 [155 kB] Get:3 http://archive.ubuntu.com/ubuntu jammy/main amd64 libpsl5 amd64 0.21.0-1.2build2 [58.4 kB] Get:4 http://archive.ubuntu.com/ubuntu jammy/main amd64 publicsuffix all 20211207.1025-1 [129 kB] Get:5 http://archive.ubuntu.com/ubuntu jammy/main amd64 wget amd64 1.21.2-2ubuntu1 [367 kB] Fetched 1893 kB in 1s (2525 kB/s) debconf: delaying package configuration, since apt-utils is not installed Selecting previously unselected package openssl. (Reading database ... 4395 files and directories currently installed.) Preparing to unpack .../openssl_3.0.2-0ubuntu1.12_amd64.deb ... Unpacking openssl (3.0.2-0ubuntu1.12) ... Selecting previously unselected package ca-certificates. Preparing to unpack .../ca-certificates_20230311ubuntu0.22.04.1_all.deb ... Unpacking ca-certificates (20230311ubuntu0.22.04.1) ... Selecting previously unselected package libpsl5:amd64. Preparing to unpack .../libpsl5_0.21.0-1.2build2_amd64.deb ... Unpacking libpsl5:amd64 (0.21.0-1.2build2) ... Selecting previously unselected package publicsuffix. Preparing to unpack .../publicsuffix_20211207.1025-1_all.deb ... Unpacking publicsuffix (20211207.1025-1) ... Selecting previously unselected package wget. Preparing to unpack .../wget_1.21.2-2ubuntu1_amd64.deb ... Unpacking wget (1.21.2-2ubuntu1) ... Setting up libpsl5:amd64 (0.21.0-1.2build2) ... Setting up wget (1.21.2-2ubuntu1) ... Setting up openssl (3.0.2-0ubuntu1.12) ... Setting up publicsuffix (20211207.1025-1) ... Setting up ca-certificates (20230311ubuntu0.22.04.1) ... debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 78.) debconf: falling back to frontend: Readline debconf: unable to initialize frontend: Readline debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the Term::ReadLine module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.34.0 /usr/local/share/perl/5.34.0 /usr/lib/x86_64-linux-gnu/perl5/5.34 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.34 /usr/share/perl/5.34 /usr/local/lib/site_perl) at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 7.) debconf: falling back to frontend: Teletype Updating certificates in /etc/ssl/certs... 137 added, 0 removed; done. Processing triggers for libc-bin (2.35-0ubuntu3.1) ... Processing triggers for ca-certificates (20230311ubuntu0.22.04.1) ... Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. root@f9b94fb28d89:/# wget https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-x86_64.sh --2023-12-05 07:22:07-- https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-x86_64.sh Resolving github.com (github.com)... 192.30.255.113 Connecting to github.com (github.com)|192.30.255.113|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://github.com/conda-forge/miniforge/releases/download/23.3.1-1/Miniforge3-Linux-x86_64.sh [following] --2023-12-05 07:22:07-- https://github.com/conda-forge/miniforge/releases/download/23.3.1-1/Miniforge3-Linux-x86_64.sh Reusing existing connection to github.com:443. HTTP request sent, awaiting response... 302 Found Location: https://objects.githubusercontent.com/github-production-release-asset-2e65be/221584272/6b843e17-f2d2-49f7-8fca-702997a3762d?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20231205%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20231205T072208Z&X-Amz-Expires=300&X-Amz-Signature=e6c8b111bc7d341ae30d7e31c2cdd61ef940e4d4ec1767baf800df044fa4e32e&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=221584272&response-content-disposition=attachment%3B%20filename%3DMiniforge3-Linux-x86_64.sh&response-content-type=application%2Foctet-stream [following] --2023-12-05 07:22:08-- https://objects.githubusercontent.com/github-production-release-asset-2e65be/221584272/6b843e17-f2d2-49f7-8fca-702997a3762d?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20231205%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20231205T072208Z&X-Amz-Expires=300&X-Amz-Signature=e6c8b111bc7d341ae30d7e31c2cdd61ef940e4d4ec1767baf800df044fa4e32e&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=221584272&response-content-disposition=attachment%3B%20filename%3DMiniforge3-Linux-x86_64.sh&response-content-type=application%2Foctet-stream Resolving objects.githubusercontent.com (objects.githubusercontent.com)... 185.199.111.133, 185.199.108.133, 185.199.109.133, ... Connecting to objects.githubusercontent.com (objects.githubusercontent.com)|185.199.111.133|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 87007851 (83M) [application/octet-stream] Saving to: 'Miniforge3-Linux-x86_64.sh' Miniforge3-Linux-x86_64.sh 100%[====================================================================================================================================================>] 82.98M 108MB/s in 0.8s 2023-12-05 07:22:08 (108 MB/s) - 'Miniforge3-Linux-x86_64.sh' saved [87007851/87007851] root@f9b94fb28d89:/# bash Miniforge3-Linux-x86_64.sh Welcome to Miniforge3 23.3.1-1 In order to continue the installation process, please review the license agreement. Please, press ENTER to continue >>> Miniforge installer code uses BSD-3-Clause license as stated below. Binary packages that come with it have their own licensing terms and by installing miniforge you agree to the licensing terms of individual packages as well. They include different OSI-approved licenses including the GNU General Public License and can be found in pkgs/mamba info / micromamba info
Logs
environment.yml
No response
~/.condarc
No response