necaris / conda.el

Emacs helper library (and minor mode) to work with conda environments

conda.el

Emacs library for working with conda environments, largely ported from virtualenvwrapper.el.

what it does

• Makes Python shells, interactive shells, eshell, anaconda-mode, and so on aware of your conda environments
• Detects and auto-activates the right conda environment for a particular buffer.

running tests

Using makem.sh:

make v=v sandbox=/tmp install-deps=t test-ert

make v=v`

basic usage

• Install conda (included if you have installed Anaconda or Miniconda)

• Install from MELPA (M-x package-install conda), or just put conda.el on your load path.

• Add it to your configuration (e.g. your .emacs or init.el). Something like this should work:

  (require 'conda)
  ;; if you want interactive shell support, include:
  (conda-env-initialize-interactive-shells)
  ;; if you want eshell support, include:
  (conda-env-initialize-eshell)
  ;; if you want auto-activation (see below for details), include:
  (conda-env-autoactivate-mode t)
  ;; if you want to automatically activate a conda environment on the opening of a file:
  (add-to-hook 'find-file-hook (lambda () (when (bound-and-true-p conda-project-env-path)
                                            (conda-env-activate-for-buffer))))

• If your Anaconda installation is anywhere other than the default (~/.anaconda3) then set the conda-anaconda-home custom variable to the installation path. For instance, if you installed miniconda via Homebrew on macOS, this should work:

  (custom-set-variables
   '(conda-anaconda-home "/usr/local/Caskroom/miniconda/base/"))

  Also, if you have configured your Anaconda environment directory differently from the default (i.e. not relative to the Anaconda installation), you additionally need to set the conda-env-home-directory. For example, if it's at ~/anaconda3/ (while your main Anaconda installation might be at /opt/anaconda):

  (setq conda-env-home-directory (expand-file-name "~/anaconda3/"))
  

  Especially if you've changed from the default configuration, be sure to double-check that your Conda environments are correctly located. The default subdirectory is envs, so if your conda-env-home-directory is ~/anaconda3 then by default environments will be looked for in ~/anaconda3/envs. You can change this with the conda-env-subdirectory setting:

  (setq 
    conda-env-home-directory (expand-file-name "~/anaconda3/") ;; as in previous example; not required
    conda-env-subdirectory "myenvs")
  

  Now environments will be searched for under ~/anaconda3/myenvs.

• Use M-x conda-env-activate to activate conda environments and M-x conda-env-deactivate to deactivate them. You can also use M-x conda-env-activate-for-buffer to try and detect the correct conda environment for a buffer, or use the conda-env-autoactivate-mode minor mode to do this automatically (see below for more details).

what do activating and deactivating actually do?

As with virtualenvwrapper.el, activating a conda environment does:

1. Sets python-shell-virtualenv-path to the environment's directory so that when you open a new python shell, it is aware of the environment's installed packages and modules.
2. The environment's bin directory is prepended to the PATH environment variable and Emacs' internal exec-path, so that when a process is launched from Emacs it is aware of any executables installed in the virtualenv (e.g py.test, pep8, etc.). This comes in handy for FlyCheck to correctly lint your code, or to use M-! nosetests to run your tests, and so on.
3. The VIRTUAL_ENV environment variable is set to the environment's directory so any tools that depend on this variable function correctly (such as jedi).
4. pythonic-activate is called on the environment to ensure any other Python- related code is initialized with the right working path, version of Python, and so on.

When you deactivate, all these things are undone. You can safely modify your PATH and exec-path while a virtualenv is active and expect the changes not to be destroyed.

This covers everything except interactive shells, which are covered in the next section.

shells

This thing supports two types of interactive shells, the eshell and the interactive subshell (what you get when you do M-x shell).

interactive shell

Support for interactive shell is turned on by calling conda-env-initialize-interactive-shell. After this is done, whenever you call shell, the shell will start in the correct conda environment. Note that changing the environment in Emacs will not affect any running shells and vice-versa; they are independent processes.

WARNINGS

This feature is a pretty big hack and works by advising the shell function. This works fine if you haven't otherwise tricked out or advised it, but if this is the case it may break.

eshell

Support for eshell is turned on by calling conda-env-initialize-eshell. After doing this, any new eshells you launch will be in the correct environment and have access to installed executables, etc. The mode also provides a variety of virtualenvwrapper-like commands that work identically to their bash/zsh counterparts (described in detail below). Note that in contrast to how interactive shells work, Eshell shares an environment with Emacs, so if you activate or deactivate in one, the other is affected as well. Note that this requires the variable eshell-modify-global-environment to be set to true -- running conda-env-initialize-eshell causes this to occur.

command reference

The commands this mode provides are prefixed with conda- (right now, the majority start with conda-env- since they deal with environments). All commands can be called interactively using M-x. Many of these commands have also been aliased without prefixes as eshell functions, so you can call them on the eshell just as you would in bash or zsh. For example:

eshell> activate myenv
eshell> deactivate

All will do what would expect.

conda-env-activate

Prompts for the name of a conda environment and activates it as described above. Can also be called noninteractively as (conda-env-activate "<NAME>").

conda-env-deactivate

Deactivates the current conda environment, undoing everything that conda-env-activate did. This can also be called noninteractively as (conda-env-deactivate).

conda-env-list

List all available conda environments, in a temp buffer.

useful macros

There is a conda-with-env macro, which takes the name of a conda environment and then any number of forms and executes those forms with that environment active.

Since it's common to want to execute shell commands, there is a convenience macro conda-with-env-shell-command, which takes a string, interpreted as a shell command, and do exactly what you'd expect. So for example, you can do (conda-with-env-shell-command "myenv" "conda install pep8") to install pep8 in the myenv conda environment. It can also be called interactively and will prompt for a command to run if so.

keybindings

Just like virtualenvwrapper.el, no keybindings defined here. Do what you like!

automatically activating a virtualenv in a particular project

It's also common to want to have an environment automatically activated when you open a file in a certain project. This can be done with the conda-env-autoactivate-mode minor mode, which will:

• check for a per-directory local variable setting the conda-project-env-path variable with either the name or the full path to an existing conda environment
• search up the directory tree for a file defining a conda environment, such as an environment.yml file, and try to activate the named environment

displaying the currently active environment on the mode line

The name of the currently active conda environment is stored in the variable conda-env-current-name. If you want to have it displayed on your customized mode line you can just add (:exec (list conda-env-current-name))) somewhere in your mode-line-format. If you don't customize your mode line and just want to have the current virtualenv displayed, you can do:

(setq-default mode-line-format (cons '(:exec conda-env-current-name) mode-line-format))

eshell prompt customization

You might also want to have the name of your current conda environment appear on the eshell prompt. You can do this by a pretty similar mechanism, just include conda-env-current-name in your eshell-prompt-function somewhere.

More about customizing the eshell prompt on the EmacsWiki.

bugs / comments / contributions

Please open an issue or a PR! I'm happy to pull in contributions or take suggestions for improvements.

conda.el's Issues

MELPA install fails

MELPA install fails

M-x package-install conda
package--with-response-buffer-1: https://melpa.org/packages/pythonic-20191021.811.el: Not found

I note that the melpa page indicates a 2021... package, but this message shows 20191021.

buffer local variable `conda-anaconda-home' not working

If I set conda-anaconda-home as a buffer local variable, conda-env-activate can not activate the correct conda env.

Steps to reproduce the problem

Configuration

1. In init file:

   (use-package conda)

2. My python project is organized as:

   .
   ├── .dir-locals.el
   └── src
       └── main.py
   

3. In .dir-locals.el:

   ((python-mode . ((conda-anaconda-home . "/home/user/programs/miniconda3/"))))

Operations

1. open main.py
2. M-x conda-env-activate, choose environment base, enter
3. *Message* buffer shows:

   if: Error: executing command ""/home/user/.anaconda3/bin/conda" ..activate "bash" "/home/user/programs/miniconda3/"" produced error code 127
   

Specifications

• conda-20200818.1614
• emacs 27.1
• conda 4.9.2
• Arch Linux
• x86_64 Linux 5.9.14-arch1-1

conda-env-autoactivate-mode only takes effect on second visit to buffer

conda-env-autoactivate-mode doesn't take effect until you open a buffer, switch away, and then switch back. The implementation adds advice to switch-to-buffer, which is not called the first time a buffer is loaded.

Activate environments residing in custom paths

Usually I have my conda envs either in the project root directory in _venv or (sometimes) in some arbitrary directory. So not a named environment from conda create -n <name> but a prefixed from conda create -p <path>. Is there a chance to load those kind prefixed (not named) environments, too?

Tramp support?

Is there any interest in getting this to work on remote machines via TRAMP?

I find that "conda-env-list" does not produce any output

conda-env-activate: Activates local dir instead of env

In Eshell, if there is a directory named "an-env" in current working directory then activating an existing env with the same name ("an-env") via conda-env-activate does not error out, but does not work. On the Eshell prompt which python points to the wrong python and conda list shows this error

EnvironmentLocationNotFound: Not a conda environment: <absolute-path-to-an-env>

Purpose of `conda--get-path-prefix`

Hi, recently I was digging into the code and found that conda--get-path-prefix seems to perform the exact same thing that

(concat (file-name-as-directory env-dir) conda-env-executables-dir)

would for the same valid env-dir.

Example:

(conda--get-path-prefix "/path/to/anywhere")
;; outputs the same as
(concat (file-name-as-directory "/path/to/anywhere") conda-env-executables-dir)
;; given that "/path/to/anywhere" is a path to a valid directory

Since conda--get-path-prefix already makes use of conda-env-executables-dir to find the proper path to the conda command, it doesn't seem to make sense such a more complicated check performed inside of the function.

Can someone explain this further?

Unable to activate base environment

By following the guides on the landing page I'm unable to get the base environment to work.
I guess this comes from the fact that the base environment is not listed in anaconda3/envs.
Doing a clone of the base environment into a second environment with a different name works.
Currently I'm only setting

(use-package conda
  :ensure t
  :custom
  (conda-anaconda-home "/opt/anaconda3/")
  :config
  (conda-env-initialize-eshell))

Another workaround is to create a softlink called base in anaconda3/envs that points back to anaconda3/.

Is it possible that the conda-env-autoactivate-mode also deactivates the environment automatically?

Hi, nice project. Is it possible that conda.el automatically deactivates the conda environment if no conda-project-env-name is activated in conda-env-autoactivate-mode? I develop many different projects with different languages and dependencies in the same Emacs. I use projectile to manage the projects and I want to use conda.el to automatically activate the right environment. But sometimes I want to edit files which are not managed by projectile in a clean environment so I don't have unnecessary dependencies. In this case conda.el should simply deactivate the environment.

Help with custom conda directory

I'm having some trouble setting the conda home directory. I have it installed at /home/user/miniconda3. I have set the conda-anaconda-home variable to the above directory, but it does not detect the environments I have created.

Also, when I manually set the environment using M-x conda-env-activate-path, it does not seem to make any difference to Flycheck (import of packages installed only in the conda environment show up as errors).

How do I set it up correctly? Any help is appreciated.

How to actually run python in emacs once you've run conda-activate-env?

I have conda installed and correctly configured so that it seems that I can successfully target one of my conda environments. From the Messages buffer:

Mark set [2 times]
Switched to conda environment: d:/pat/miniconda3/envs/cubeenv/
Quit [2 times]

That's correct - however, when I run-python and then try to import a module that's in that environment it fails in confusing ways, and in particular it tells me that the python I'm running is the default python installed outside conda which is found under c:\users\patf\appdata\local\programs\python.

macos M-x shell produces source activate my-env BUT source not found

Things appear to work fine when I launch python code from Emacs, but when I go to the shell it would not activate the environment until I ran "conda activate my-env"

Each time in my bash history I would see "source activate my-env" and wonder where it came from.

I looked in conda.el and found this:
(defun conda-env-shell-init (process) "Activate the current env in a newly opened shell PROCESS." (let* ((activate-command (if (eq system-type 'windows-nt) '("activate") '("source" "activate"))) (full-command (append activate-command (,conda-env-current-name "\n")))
(command-string (combine-and-quote-strings full-command)))
(comint-send-string process command-string)))
`
When I change
'("source" "activate")))
to
'("conda" "activate")))

it works for me.

According to this SO post conda 4.4 and newer should use "conda activate" rather than what the previous versions used as "source activate".
https://stackoverflow.com/questions/47246350/conda-activate-not-working

conda info command in eshell doesn't reflect active env

Reproduce by running conda info in a vanilla eshell configuration (Emacs 25) and see it report "active environment : None".

It's no big deal, but might be worth fixing / documenting to avoid confusing people.

`conda-env-subdirectory` docstring references `conda-anaconda-home` instead of `conda-env-home-directory`

This is a small error which may be responsible for users not managing to configure conda.el.

I have an anaconda configuration with

• anaconda installation: /opt/anaconda/python3.6
• virtual env directory: /opt/anaconda/myenvs

This requires

(setq conda-anaconda-home "/opt/anaconda/python3.6"
		conda-env-home-directory "/opt/anaconda"
		conda-env-subdirectory "myenvs"))

Since the docstring of conda-env-subdirectory suggests that the dirname will be added to conda-anaconda-home, some people who do not look at the src code may fail to understand that they need to configure it. They will leave it at the default "envs" value.
Maybe #45 has this problem, but he does not provide enough information on his specific settings.

void-variable prev-env in conda-with-env

Calling functions using conda-with-env currently results in a void-variable error against prev-env.

To fix this, the name prev-env at

conda.el/conda.el

Line 373 in 9f7eea1

(if prev-env ;; switch back

should be renamed to prev-env-path, in line with the similar renamings in 5dc78b5

conda-env-deactivate doesn't restore PATH

In an eshell buffer:

1. (conda-env-initialize-eshell)
2. echo $PATH
3. $ activate env-name
4. echo $PATH
5. $ deactivate
6. echo $PATH

I would assume that 6. and 2. would produce the same result (as is the case when running the above in e.g. bash). However, PATH is unchaged by 5. meaning that the env env-name is still activate at 6.

`conda-env-activate` does not run activate.d scripts

M-x conda-env-activate does seem to ignore contents of the conda environment's activate.d directory

For example, my q_activate.sh script sets the QHOME environment variable and the test outside emacs works correctly:

$ echo $QHOME         # empty

$ conda activate q

(q) $ cat $CONDA_PREFIX/etc/conda/activate.d/q_activate.sh
#!/bin/bash 
export OLD_QHOME="$QHOME"
export QHOME="${CONDA_PREFIX}/q"

(q) $ echo $QHOME          # set as expected
/opt/conda/envs/q/q

In emacs and with conda.el, when I activate the q environment, the QHOME env variable is empty:

M-x conda-env-activate
HELM Conda Env Activate -> Choose a conda environment: -> q
M-: (getenv "QHOME")
""

Albeit, PATH environment variable seems to be modified correctly by the activation:

M-: (getenv "PATH")
"/opt/conda/envs/q/bin:/opt/conda/bin:/opt/conda/condabin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" 

Expected Behavior
All scripts in $CONDA_PREFIX/etc/conda/activate.d and $CONDA_PREFIX/etc/conda/deactivate.d directories should be run, as per the conda docs.

Question about Auto Activation

I have a query regarding the auto activation using dir-locals or environment.yml file
Why is auto activation activating the virtual environment every time i switch buffers?
Isn't it enough to activate only once when the buffer is created initially with the file name?

No conda environment for file

Every time I visit any file, I get a message like this:

No conda environment for file <c:/Users/scotto/OneDrive/scotto/ANY_FILE>

Would it be possible to print this message only when I've visited a python file?

environment aware repl

Sorry if this is stupid but can you give details how to evaluate the buffer in the active conda environment? I'm using Elpy. If I C-c C-c it doesn't run in the right environment. The Readme says "Support for interactive shell is turned on by calling conda-env-initialize-interactive-shell" but that isn't an option when I do tab completion M-x conda-[tab].

conda--get-name-from-env-yml fails on environment names that include hyphens

Currently, the environment file is searched with the following regexp:

"name:[ ]*\\(\\w+\\)[ ]*$"

For whatever syntax class that's active in this part of the code, "w+" seems to exclude hyphens. The result is that environments with hyphens fail to be automatically detected via environment.yml.

Use conda-env-home-directory in `conda-env-location`

It's a tiny issue. We should use conda-env-home-directory in this
line rather
conda-home-directory.

Cannot activate any env on OSX

I'm not sure if I did something wrong but I can't activate anything on OSX. I have 2 envs on my systems:

$ conda info -e
# conda environments:
#
base                  *  /Users/kittipat/miniconda3
test_env                 /Users/kittipat/miniconda3/envs/test_env

When I ran conda-env-list, I got an empty buffer. I do have (custom-set-variables '(conda-anaconda-home "~/miniconda3/")) in my init file.

Here are some version infos:

$ emacs --version
GNU Emacs 26.2
$ conda --version
conda version : 4.7.10
python version : 3.7.3.final.0

I got conda.el from MELPA.

Missing dependency for string-trim

You are using string-trim in conda.el, which is defined in subr-x.
I think a

(require 'subr-x)

is missing at the very beginning.

Unable to activate environment on Windows

See #47 (comment) from @notuntoward: unable to activate an existing environment using (conda-env-activate "<name>") in .emacs, despite it showing up in the list when running M-x conda-env-activate.

conda-env-activate doesn't activate base

If I run:

(conda-env-activate "base")

I get the error: "No such conda environment: base"

But I do have a base environment:

conda env list
# conda environments:
#
base                     C:\Users\scott\Anaconda3
base_sg                  C:\Users\scott\Anaconda3\envs\base_sg
stdso                 *  C:\Users\scott\Anaconda3\envs\stdso
                         C:\tools\Anaconda3

Also, as far as I know, there's always a default base.

elpy-use-ipython: elpy-use-ipython is deprecated

When I run conda-env-activate, and select an environment, I get the following warning:

elpy-use-ipython: elpy-use-ipython is deprecated; see https://elpy.readthedocs.io/en/latest/ide.html#interpreter-setup

If, instead, I have (conda-env-autoactivate-mode t) in my .emacs, then I get an error when I start emacs:

Error (use-package): elpy/:init: elpy-use-ipython is deprecated; see https://elpy.readthedocs.io/en/latest/ide.html#interpreter-setup

This is on emacs 25.3.1 and elpy 1.18.0

(conda-env-initialize-interactive-shells) messes up 'M-x shell' on my Windows box

Hello,

I've just recently discovered conda, and have gotten it mostly set up and working. I really appreciate the package, but no matter what I do, including (conda-env-initialize-interactive-shells) in my init file seems to kill my ability to launch a shell by doing M-x shell. (Commenting it out fixes the problem.)

I am running Vincent Goulet's distribution of the following version of Emacs: GNU Emacs 25.2.1 (x86_64-w64-mingw32) of 2017-04-24 on a Windows 7 laptop. I experience the problem when I launch emacs by doing emacs -q --load /path/to/my-init.el where my-init.el is a pared down init file containing just the following:

;; "my-init.el"
(package-initialize)
(elpy-enable)

;; Temp fix for problem whose fuller solution is referenced here:
;; https://github.com/jorgenschaefer/elpy/issues/887
(setq python-shell-completion-native-enable nil)

(custom-set-variables
  '(conda-anaconda-home "C:/Users/Josh/Anaconda3"))
(require 'conda)
;; Unfortunately, this kills my ability to launch
;; into a shell with `M-x shell`. In buffer, I get:
;; "Symbol’s value as variable is void: buffer"
(conda-env-initialize-interactive-shells)

Incorrect Windows path to conda.exe after #57

On my Windows machine, Anaconda has installed conda.exe in:

c:/Users/scott/anaconda3/Scripts/conda.exe

but since #57, the conda package looks for it in:

c:/Users/scott/anaconda3/bin/conda

Or so it seems, if I look at the error message emacs gives me when I try to activate an environment named "stdso":

Error (use-package): conda/:config: Error: executing command
"c:/Users/scott/anaconda3/bin/conda ..activate "cmd.exe"
c:/Users/scott/anaconda3/envs/stdso" produced error code 1

Before #57, I think that the conda package looked in my PATH environment variable for a conda.exe, which worked correctly.

I have set both conda-env-home-directory and conda-anaconda-home to:

c:/Users/scott/anaconda3

End of file during parsing

The latest version of conda.el coming from elpa won't compile. Here's the error message I get when I try:

Compiling file c:/Users/scott/.emacs.d/elpa/conda-20210407.1802/conda.el at Thu Apr  8 09:13:21 2021
conda.el:401:1:Error: End of file during parsing

Some environments don't activate with dir-locals

I started a new project with a new conda env, but for some reason the new env is not activated in emacs.
I have the following in my .dir-locals.el:

((python-mode . ((eval . (conda-env-activate "newenv")))))

It doesn't activate the env when I open a file from the folder.

However, if I change to another env that I've been using for some time, i.e.:

((python-mode . ((eval . (conda-env-activate "oldenv")))))

then it works without any issues.

There is no error message of anything. Any ideas?

activating environment does not set additional environment variables

Conda provides the ability to set the environment variable of your choice upon entry to a conda environment using the conda env config vars set command. I have set LD_LIBRARY_PATH in my development environment, in order to pick up some shared libraries:

$ echo $LD_LIBRARY_PATH

$ conda activate gtdev
(gtdev) $ echo $LD_LIBRARY_PATH
/home/jet/boost_1_71_0/stage/lib
(gtdev) $

Unfortunately when I execute a file (using C-c C-c in elpy) I find that the resulting Python execution shell does not have it set:

ImportError: libboost_iostreams.so.1.71.0: cannot open shared object file: No such file or directory

>>> import os
>>> print(os.environ['LD_LIBRARY_PATH'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jet/miniconda3/envs/gtdev/lib/python3.7/os.py", line 681, in __getitem__
    raise KeyError(key) from None
KeyError: 'LD_LIBRARY_PATH'
>>> 

Does conda.el support this functionality? Have I misconfigured it? Thanks.

Can't activate conda environment

I'm trying to activate a working conda environment from conda.el to no avail. I'm using the conda spacemacs layer. I have an environment called test_ds which is located in ~/opt/anaconda3/envs/. Here's my conda.el config:

conda-anaconda-home "~/opt/anaconda3/"
conda-env-autoactivate-mode t

If I activate the environment manually, it works:

conda activate test_ds

but if I set it through conda-env-activate it errors with:

"Error: executing command \"\"~/opt/anaconda3/bin/conda\" ..activate \"bash\" \"/Users/cimentadaj/opt/anaconda3/envs/test_ds/\"\" produced error code 127"

Here's the traceback:

(error "Error: executing command \"\"~/opt/anaconda3/bin/conda\" ..activate \"bash\" \"/Users/cimentadaj/opt/anaconda3/envs/test_ds/\"\" produced error code 127")
* signal(error ("Error: executing command \"\"~/opt/anaconda3/bin/conda\" ..activate \"bash\" \"/Users/cimentadaj/opt/anaconda3/envs/test_ds/\"\" produced error code 127"))
  error("Error: executing command \"\"~/opt/anaconda3/bin/conda\" ..activate \"bash\" \"/Users/cimentadaj/opt/anaconda3/envs/test_ds/\"\" produced error code 127")
  conda--get-path-prefix("/Users/cimentadaj/opt/anaconda3/envs/test_ds/")
  conda-env-activate-path("/Users/cimentadaj/opt/anaconda3/envs/test_ds/")
  conda-env-activate("test_ds")
  (progn (conda-env-activate "test_ds"))
  eval((progn (conda-env-activate "test_ds")) t)
  elisp--eval-last-sexp(nil)
  #f(compiled-function (eval-last-sexp-arg-internal) "Evaluate sexp before point; print value in the echo area.\nInteractively, with a non `-' prefix argument, print output into\ncurrent buffer.\n\nNormally, this function truncates long output according to the\nvalue of the variables `eval-expression-print-length' and\n`eval-expression-print-level'.  With a prefix argument of zero,\nhowever, there is no such truncation.\nInteger values are printed in several formats (decimal, octal,\nand hexadecimal).  When the prefix argument is -1 or the value\ndoesn't exceed `eval-expression-print-maximum-character', an\ninteger value is also printed as a character of that codepoint.\n\nIf `eval-expression-debug-on-error' is non-nil, which is the default,\nthis command arranges for all errors to enter the debugger." (interactive "P") #<bytecode 0x410e610f>)(nil)
  #f(compiled-function (&rest _it) #<bytecode 0x1fee60ea1c99>)()
  eval-sexp-fu-flash-doit-simple(#f(compiled-function (&rest _it) #<bytecode 0x1fee60ea1c99>) #f(compiled-function (&rest args2) #<bytecode 0x1fee6390ea4d>) #f(compiled-function (&rest args2) #<bytecode 0x1fee6390ea6d>))
  eval-sexp-fu-flash-doit(#f(compiled-function (&rest _it) #<bytecode 0x1fee60ea1c99>) #f(compiled-function (&rest args2) #<bytecode 0x1fee6390ea4d>) #f(compiled-function (&rest args2) #<bytecode 0x1fee6390ea6d>))
  esf-flash-doit(#f(compiled-function (&rest _it) #<bytecode 0x1fee60ea1c99>) #f(compiled-function (&rest args2) #<bytecode 0x1fee6390ea4d>) #f(compiled-function (&rest args2) #<bytecode 0x1fee6390ea6d>) #f(compiled-function (&rest args2) #<bytecode 0x1fee6390ea8d>))
  ad-Advice-eval-last-sexp(#f(compiled-function (eval-last-sexp-arg-internal) "Evaluate sexp before point; print value in the echo area.\nInteractively, with a non `-' prefix argument, print output into\ncurrent buffer.\n\nNormally, this function truncates long output according to the\nvalue of the variables `eval-expression-print-length' and\n`eval-expression-print-level'.  With a prefix argument of zero,\nhowever, there is no such truncation.\nInteger values are printed in several formats (decimal, octal,\nand hexadecimal).  When the prefix argument is -1 or the value\ndoesn't exceed `eval-expression-print-maximum-character', an\ninteger value is also printed as a character of that codepoint.\n\nIf `eval-expression-debug-on-error' is non-nil, which is the default,\nthis command arranges for all errors to enter the debugger." (interactive "P") #<bytecode 0x410e610f>) nil)
  apply(ad-Advice-eval-last-sexp #f(compiled-function (eval-last-sexp-arg-internal) "Evaluate sexp before point; print value in the echo area.\nInteractively, with a non `-' prefix argument, print output into\ncurrent buffer.\n\nNormally, this function truncates long output according to the\nvalue of the variables `eval-expression-print-length' and\n`eval-expression-print-level'.  With a prefix argument of zero,\nhowever, there is no such truncation.\nInteger values are printed in several formats (decimal, octal,\nand hexadecimal).  When the prefix argument is -1 or the value\ndoesn't exceed `eval-expression-print-maximum-character', an\ninteger value is also printed as a character of that codepoint.\n\nIf `eval-expression-debug-on-error' is non-nil, which is the default,\nthis command arranges for all errors to enter the debugger." (interactive "P") #<bytecode 0x410e610f>) nil)
  eval-last-sexp(nil)
  lisp-state-eval-sexp-end-of-line()
  funcall-interactively(lisp-state-eval-sexp-end-of-line)
  call-interactively(lisp-state-eval-sexp-end-of-line nil nil)
  command-execute(lisp-state-eval-sexp-end-of-line)

Is this a bug or am I doing something wrong? Let me know and I'll move this for SO in case it's a question.

NotImplemented: Check for a per-directory local variable setting the conda-project-env-name

Hello,

Thank you for the great module. I noticed that the following is not implemented (at least not on the master branch)

It's also common to want to have an environment automatically activated when you open a file in a certain project. This can be done with the conda-env-autoactivate-mode minor mode, which will:
   - check for a per-directory local variable setting the conda-project-env-name

This part of the code is putting it as a TODO, maybe it was implemented an then reversed...

(defun conda--read-env-name ()
  "Read environment name, prompting appropriately whether an env is active now."
  ;; TODO FEATURE: does this need to be inferred from the directory?
  (conda-env-read-name
   (format "Choose a conda environment%s: "
           (if conda-env-current-name
               (format " (currently %s)" conda-env-current-name)
             ""))))

[BUG] conda-env-activate-for-buffer error

conda-env-activate-for-buffer produces the following error.

Symbol’s value as variable is void: conda-project-env-name

Buffer local environments

I'm enjoying using the package for manually activating and deactivating conda environments. So long as I do things manually everything seems to work out just right so thanks for making this package.

I tried out conda-env-autoactivate-mode but I didn't really do what I was expecting at all. I think this is for two reasons. First, the environment check is done on switch-buffer. This seems to both be too often and not often enough - it doesn't find the environment when you first find a file but then checks if you swap between buffers in the same project (with the same environment) even if you've already visited and correctly set the environment.

I'd like to make an enhancement suggestion. I'm not sure if this is possible to be honest but I hoped you might be able to help. Can the environment be made buffer-local? If this was possible the environment could be set when the file is opened then you wouldn't need to check any further. Does this make sense? Would this even be possible?

This would also allow me to switch quickly between projects without changing environments lots (which seems to be the aim of conda-env-autoactivate-mode and also provide a solution for #64.

`conda-env-deactivate` is broken by recent changes to `conda-env-stripped-path`

I just updated (;; Package-Version: 20190528.421) and can't activate an environment now.

conda-env-stripped-path now tries to split a PATH string into a list of strings, but it is being fed exec-path in conda-env-deactivate, which is already a list of strings.

Debugger entered--Lisp error: (wrong-type-argument stringp ("/home/james/bin" "/usr/local/sbin" "/usr/local/bin" "/usr/sbin" "/usr/bin" "/sbin" "/bin" "/usr/games" "/usr/local/games" "/snap/bin" "/usr/local/libexec/emacs/26.2/x86_64-pc-linux-gnu"))
  string-match(":" ("/home/james/bin" "/usr/local/sbin" "/usr/local/bin" "/usr/sbin" "/usr/bin" "/sbin" "/bin" "/usr/games" "/usr/local/games" "/snap/bin" "/usr/local/libexec/emacs/26.2/x86_64-pc-linux-gnu") 0)
  split-string(("/home/james/bin" "/usr/local/sbin" "/usr/local/bin" "/usr/sbin" "/usr/bin" "/sbin" "/bin" "/usr/games" "/usr/local/games" "/snap/bin" "/usr/local/libexec/emacs/26.2/x86_64-pc-linux-gnu") ":" nil)
  (progn (split-string s separator omit-nulls))
  (unwind-protect (progn (split-string s separator omit-nulls)) (set-match-data save-match-data-internal (quote evaporate)))
  (let ((save-match-data-internal (match-data))) (unwind-protect (progn (split-string s separator omit-nulls)) (set-match-data save-match-data-internal (quote evaporate))))
  s-split(":" ("/home/james/bin" "/usr/local/sbin" "/usr/local/bin" "/usr/sbin" "/usr/bin" "/sbin" "/bin" "/usr/games" "/usr/local/games" "/snap/bin" "/usr/local/libexec/emacs/26.2/x86_64-pc-linux-gnu"))
  conda-env-stripped-path(("/home/james/bin" "/usr/local/sbin" "/usr/local/bin" "/usr/sbin" "/usr/bin" "/sbin" "/bin" "/usr/games" "/usr/local/games" "/snap/bin" "/usr/local/libexec/emacs/26.2/x86_64-pc-linux-gnu"))
  conda-env-deactivate()
  conda-env-activate()
  funcall-interactively(conda-env-activate)
  call-interactively(conda-env-activate record nil)
  command-execute(conda-env-activate record)
  #f(compiled-function (cmd) #<bytecode 0x1b4de25>)("conda-env-activate")

exec-path not set with activate

exec-path was not set up correctly so I commented the following line

(let ((path-prefix (conda--get-path-prefix env-dir)))
          ;; setup emacs exec-path
          ;; (dolist (env-exec-dir (parse-colon-path path-prefix))  ; comment out
            (add-to-list 'exec-path env-exec-dir)
	    ;; )  ;; comment out
          ;; setup the environment for subprocesses, eshell, etc
          (setenv "PATH" (concat path-prefix path-separator (getenv "PATH"))))

I am not sure what conda--get-path-prefix is meant to do, but it gives me the empty string in linux on my env dir (or any directory). And the previous env-exec-dir let would have been lost

(let* ((env-dir (conda-env-name-to-dir env-name))
             (env-exec-dir (concat (file-name-as-directory env-dir)
                                   conda-env-executables-dir)))
....

Doesn't register new anaconda environments Win10

I just created a new environment using the anaconda prompt, but it doesn't show up in the conda-env-list buffer. There are no packages installed in the new environment.

Interactive-Shell Issue: <env_name>: command not found

I am having trouble getting conda.el to work well with my interactive shell (M-x shell).
When I run M-x conda-env-activate <env_name> and then run M-x shell I get:
<env_name>: command not found

Presumably conda.el is missing the conda activate part when initializing the shell, but I'm not sure why?

Here is my setup, which is slightly non-standard because my conda home director is in /anaconda3/ instead of ~anaconda3/.

(use-package conda
  :ensure t
  :init
  (progn
    (require 'conda)
    (custom-set-variables
     '(conda-anaconda-home "/anaconda3/"))
    (setq conda-env-home-directory (expand-file-name "/anaconda3/"))
    (conda-env-initialize-interactive-shells)
    (conda-env-initialize-eshell)
    (conda-env-autoactivate-mode t)
))

Thanks!

Doesn't work on Windows

On Windows, the <env>\Scripts\ directory doesn't contain python.exe so even after activating the env with conda.el, M-x run-python, eshell etc. still use the system Python.

The env-specific python.exe is in the parent directory, i.e. the root <env> directory.

Can try pushing a PR to fix sometime next week.

Unable to launch terminal emulator when base env. activated

Context

I have the utility function shown below to launch a terminal emulator (outside Emacs) at the current directory. The OS is Linux.

(defun acg/open-in-terminal ()
  "Open the current dir in a new terminal window.
URL `http://ergoemacs.org/emacs/emacs_dired_open_file_in_ext_apps.html'
Version 2015-12-10"
  (interactive)
  (cond
   ((or (string-equal system-type "windows-nt")
        (string-equal system-type "darwin")
    (message "Not supported."))
   ((string-equal system-type "gnu/linux")
    (let ((process-connection-type nil))
      (start-process "" nil "x-terminal-emulator"
                     (concat "--working-directory=" default-directory))))))

Issue

When the "base" conda env is activated in Emacs using this package, no terminal emulator is launched. The process seems to be started, since I get a return value #<process >, but no terminal is actually shown.

Either deactivating the environment with conda-env-deactivate or switching to another environment that is not "base" makes it work.

eshell: print active env in prompt

Print active env name in eshell prompt the way other shells do it, e.g. "(base)" or "(env-name)" prepended to regular eshell prompt. This would likely be solved providing a conda-env-eshell-prompt function to serve as eshell-prompt-function. What do you think? Another thing would be to make it compatible with existing prompt functions, e.g. the ones from eshell-prompt-extras.

conda.el no longer seems to work with conda 4.6.1

I diagnosed this by adding the following line to ~/.condarc:

allow_conda_downgrades: true

This let me alternate between these two conda versions in my base environment (I am using miniconda):

conda install conda=4.5.12 # Works

and

conda install conda==4.6.1 # Doesn't work

Restarting emacs between these two versions, I can run conda-env-activate and verify that running which python using a shell command (i.e via M-!) results in the appropriate path when using conda 4.5.12 (e.g ~/miniconda3/envs/{ENV}/bin/python) but this path is inappropriate when using 4.6.1 (~/miniconda3/bin/python). My best guess is there has been some change in how environment activation works.

This is a shame as 4.6.1 has some nice improvements in solver speed!

"s-join: Wrong type argument: sequencep, 47" followed by "s-join: Wrong type argument: listp, ..."

This may be related to a few other recent issues (#32, #36, #15, #19), but I wasn't sure.

When I run conda-env-activate, I first get the following error:

s-join: Wrong type argument: sequencep, 47

If I run it again, I get:

s-join: Wrong type argument: listp, "/Users/sfp/miniconda3/bin/:/Users/sfp/miniconda3/condabin/:/usr/local/bin/:/usr/bin/:/bin/:/usr/sbin/:/sbin/:/Library/TeX/texbin/:/opt/X11/bin/:/Applications/Emacs.app/Contents/MacOS/bin-x86_64-10_10/:/Applications/Emacs.app/Contents/MacOS/libexec-x86_64-10_10/:/Applications/Emacs.app/Contents/MacOS/libexec/"

Output of M-x version:

GNU Emacs 26.1 (build 1, x86_64-apple-darwin14.5.0, NS appkit-1348.17 Version 10.10.5 (Build 14F2511)) of 2018-05-30

Using version 20190531.1807 installed from melpa.

Please let me know if there's anything I can do to help out with debugging this.

Exec path is set incorrectly

I'm having an issue with the exec-path.

https://github.com/necaris/conda.el/blob/master/conda.el#L184
This function seems to return "" on my system. This results in nil being added to the exec path, and this breaks subsequent conda-env-deactivate calls.

After some debugging, it seems like it fails because the command conda isn't found. I can resolve the issue locally by fully specifying the path of the conda command (i.e. i replace the substring conda with the path of the conda executable)

Any idea why this is happening?

conda-env-activate produced error code 127

Hello,
I have been using the conda package for a while through spacemacs with no issues. But recently when activating my environment I get the following error message:

helm-M-x-execute-command: Error: executing command ""~/miniconda3/bin/conda" ..activate "bash" "/home/pim/miniconda3/envs/batch"" produced error code 127

I suppose that it's a recent update from conda.el that is the cause, as i have tried deleting the conda folder from my elpa dir, but still am facing the issue.

Spacemacs is using conda-20200525.208

Using conda-environments with org-babel

Is it possible to set org-babel to use the conda environment settings? When I start a standard python session in emacs, it works flawlessly and uses the conda environment. However, when I'm using org-babel it always falls back to using the system version of python (and ipython).

`pop-to-buffer` vs `switch-to-buffer`

In dcd47f4, @dwa changed the buffer-switching function that conda--switch-buffer-auto-activate is used to advise for, from switch-to-buffer to pop-to-buffer without much explanation.

In my use case (latest Doom Emacs (27.1) with pretty much default settings), this change makes the auto-activation stop to work for most of the buffer-switching operations including evil-switch-to-windows-last-buffer and +ivy/switch-workspace-buffer, because they call switch-to-buffer to switch buffers while it seems that under the hood, pop-to-buffer is only used by switch-to-buffer for part of the cases.

Therefore I'm bringing up this discussion and definitely would like to learn more about this change.

conda-env-current-name not defined: How to set global-mode-string?

conda-env-current-name appears to be no longer defined, but the README still says that it is to be used for
updating global-mode-string.
How are we now supposed to put the current environment name in the mode string?