necaris / conda.el Goto Github PK

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>

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.

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).

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

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.

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.

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!

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!

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?

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.

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?

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")

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

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.

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.

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.

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.

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?

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.

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/.

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?

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.

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

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

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.

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)

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)))
....

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.

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.

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

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-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?

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.

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.

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.

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)
             ""))))

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

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?

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?

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

To fix this, the name prev-env at

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.

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.

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

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

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.

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.

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.

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.

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

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.

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