---- On Sun, 12 Feb 2023 22:16:16 -0500 Jack Kamm wrote --- > But I also noticed another prompt-related issue: conda doesn't seem to > work in ob-shell sessions anymore. That is a bigger problem for my use > case.
Could you elaborate? It looks like conda has a new init (from what I remember) which requires users to run a `conda init <shell>' command in order to create a new environment. For example, I needed to run `conda init bash.' This added garbage to my .bashrc which automatically enabled the base environment. I was able to do this from ob-shell, however it required me to reload the shell (I reloaded Emacs to be sure I got the latest environment variables). After this, I was able to create and activate a new conda environment. 1. M-x shell 2. Executing the following in sequence: #+begin_src emacs-lisp (org-version nil t) #+end_src #+RESULTS: : Org mode version 9.6.1 (release_9.6.1-250-ge6353d @ /home/user/Projects/org-mode/lisp/) #+begin_src emacs-lisp (org-babel-do-load-languages 'org-babel-load-languages '((shell . t))) #+end_src #+begin_src sh :session *shell* :results output conda create --yes --name myenv python=3.9 #+end_src #+RESULTS: #+begin_example <results removed for brevity> Downloading and Extracting Packages Preparing transaction: done Verifying transaction: done Executing transaction: done To activate this environment, use conda activate myenv To deactivate an active environment, use conda deactivate #+end_example #+begin_src sh :session *shell* :results output conda activate myenv #+end_src #+RESULTS: #+begin_src sh :session *shell* :results output which python #+end_src #+RESULTS: : /home/user/miniconda3/envs/myenv/bin/python The *shell* buffer's prompt also showed the expected [myenv] prefix.