Closed AbstractMonkey closed 1 year ago
libmamba
does not respond to Ctrl+C, as reported in the following issues:
There's an open PR that apparently would help, but it has been there for a year :/
I've moved this issue from the conda repo here btw.
Looking into this now. I'll be using this comment as my notepad.
The facts:
conda 22.9.0 py39h06a4308_0 defaults
conda-libmamba-solver 22.3.1 pyhd3eb1b0_0 defaults
libarchive 3.4.2 h62408e4_0 defaults
libcurl 7.84.0 h91b91d3_0 defaults
libmamba 0.22.1 h1566912_0 defaults
libmambapy 0.22.1 py39hd09550d_0 defaults
libsolv 0.7.20 h4ff587b_0 defaults
I'll try to reproduce first on a Linux Docker image:
$ conda info
active environment : base
active env location : /opt/conda
shell level : 1
user config file : /home/test_user/.condarc
populated config files :
conda version : 23.1.0
conda-build version : 3.23.3
python version : 3.9.16.final.0
virtual packages : __archspec=1=aarch64
__glibc=2.31=0
__linux=5.10.25=0
__unix=0=0
base environment : /opt/conda (read only)
conda av data dir : /opt/conda/etc/conda
conda av metadata url : None
channel URLs : https://repo.anaconda.com/pkgs/main/linux-aarch64
https://repo.anaconda.com/pkgs/main/noarch
https://repo.anaconda.com/pkgs/r/linux-aarch64
https://repo.anaconda.com/pkgs/r/noarch
package cache : /opt/conda/pkgs
/home/test_user/.conda/pkgs
envs directories : /home/test_user/.conda/envs
/opt/conda/envs
platform : linux-aarch64
user-agent : conda/23.1.0 requests/2.28.1 CPython/3.9.16 Linux/5.10.25-linuxkit debian/11 glibc/2.31
UID:GID : 1001:1001
netrc file : None
offline mode : False
$ conda list --show-channel-urls | grep -e libmamba -e libsolv -e archive
conda-libmamba-solver 23.1.0 <dev>
libarchive 3.6.2 h34a02f0_0 defaults
libmamba 1.0.0 hb7c5912_0 defaults
libmambapy 1.0.0 py39hb7c5912_0 defaults
libsolv 0.7.22 h94b7715_0 defaults
Ugh, ok, I see the issue. You didn't quote tensorflow>=2.10
, so it interpreted the >
as a redirect to a file named =2.10
(the ones you attached), that's why we didn't see any output. Still, even without quoting, I do see a quick successful conclusion with the specs above if I do a dry-run (because it goes to stderr):
$ CONDA_SUBDIR=linux-64 conda create -n mambaflow tensorflow>=2.10 --solver=libmamba --dry-run
DryRunExit: Dry run. Exiting.
What I suggest we do:
tensorflow
spec so we see the output in the stdout, and maybe find out what's going on. It looks like it was waiting on your input in the prompt, so it doesn't seem to be a conda or conda-libmamba-solver issue.Let us know @AbstractMonkey!
Closing for now. Feel free to reopen if it happened again with the new releases (specially 23.3, coming soon).
Checklist
What happened?
Attempted to create a Tensorflow environment a few times (in Ubuntu via WSL2) to experiment with the exciting and promising conda-libmamba-solver, but it seemed to lock up each time. Steps taken:
Prepared conda with:
Issued:
conda create -n mambaflow tensorflow>=2.10 --experimental-solver=libmamba
which apparently froze the terminal. No rapid-fire live updates; static:![image](https://user-images.githubusercontent.com/20564327/193257818-3051901a-046a-41a5-afb5-89d4e043bf88.png)
Task managers showed WSL2's memory footprint ballooning to over 7 gigs, despite attempts to Ctrl-C cancel or manually terminate the process(es), so something was definitely still running.
Ended up needing a restart, but was able to create a new env after removing libmamba and reverting to the default solver:
The logs showed libmamba busily creating the environment until needing user input. Hopefully it's as simple as a terminal output issue, because it appears everything else is working fine.
Conda info
Conda config
Conda list
Log file & additional context
=2.9.log =2.10.log