Default kernel of ob-ein when using Conda

[yatsky]

Hi,

Love EIN and thank you for all the efforts in making it a great tool!

I'm currently having an issue with ob-ein. My current setup is Windows 10, Emacs 26.2, EIN 20191110.1647, and Anaconda.

The problem

ipynb files default to using the data (virtual) environment, but ob-ein source blocks default to using Anaconda root environment.

Steps to reproduce

1. open command line prompt
2. activate data environment
3. start Emacs from the cmd
4. run M-x ein:run in Emacs
5. open an org file
6. type the following:

   #+NAME: Python sanity check
   #+begin_src ein-python :session localhost:8888/test.ipynb :results raw drawer 
   import sys
   sys.executable
   #+end_src

7. get the following, which is the default python path for Anaconda

   #+RESULTS: Python sanity check
   :results:
   'C:\\Program Files (x86)\\Microsoft Visual Studio\\Shared\\Anaconda3_64\\python.exe'
   :end:

   I'm able to run ein:run in Emacs and edit/run cells without a problem in a notebook. That is, the notebook will default to using the python.exe in the data environment.

Steps to mitigate the problem

Since the code above was actually saved in the test.ipynb, the following manual fix mitigates the problem.

1. open the test.ipynb notebook
2. click the kernel option on the top left corner of the test.ipynb buffer
3. change kernel to python3, which is under the data environment
4. go back to the source block in org file
5. run C-c C-c again
6. get the following:

   #+RESULTS: Python sanity check
   :results:
   'C:\\Users\\username\\AppData\\Local\\conda\\conda\\envs\\data\\python.exe'
   :end:

Further

Because Just specifying {url-or-port} executes your source block in a single anonymous notebook, I was not able to fix this source block:

#+NAME: Python sanity check
#+begin_src ein-python :session localhost :results raw drawer 
import sys
sys.executable
#+end_src

#+RESULTS: Python sanity check
:results:
'C:\\Program Files (x86)\\Microsoft Visual Studio\\Shared\\Anaconda3_64\\python.exe'
:end:

Thanks!

[yatsky]

Don't want to be a troll today but really need to share this temporary fix that I found after posting the issue. The anonymous notebook is called .ein-python.ipynb. If you open this notebook buffer and change its kernel to your desired kernel, everything will work beautifully. If there's some fix to it, that'd wonderful. But I can live with this atm.

Hope this helps someone.

[millejoh]

For some reason I was under the impression that you could specify the kernel in the ob-src block by specifying ein-{kernel name}, but I'm probably mistaken. I'll try to investigate if I get time this week. Thanks for the report and the workaround - not troll-y at all in my opinion.

[yatsky]

Tried specifying ein-{kernel name} but to no avail. I also tried to run M-x ein:stop and then M-x ein:run, and the src block is still running the desired kernel (data). After restarting Emacs in the data venv, then M-x ein:run, and running the same src block, it did give the same result 'C:\Users\username\AppData\Local\conda\conda\envs\data\python.exe', but the .ein-python.ipynb tells me this: unknown: please click and select a kernel. I clicked it and first two times it gave some error and didn't allow me to change kernel, but in the third try I was able to select the kernel. Unfortunately I wanted to run the debug command so didn't copy the error message of the first two attempts. Will see if I can reproduce the error later.

Thanks!

[millejoh]

Finally figured this one out, I think.

It is not documented, unfortunately, but you can specify a kernel via the :kernelspec parameter in the org source block. For example:

#+BEGIN_SRC ein-python :kernelspec data :results drawer
import sys
sys.executable
#+END_SRC

Be sure you use the name and not the display name of the kernel when specifying the kernelspec.

[yatsky]

Thanks. I tried it and it behaved strangely. I was able to use :kernelspec when I start Emacs the first time. After that, when I tried to run the same code block again, it gave me the following message. This happens before and after I upgraded to the latest EIN (currently at 20191117.2312). Another weird issue (and probably related to this one) is that I can't run ein:run right after I start Emacs as it complains that the command is not found, but after I run ein:stop, then I can run ein:run.

Debugger entered--Lisp error: (wrong-type-argument ein:$kernelspec nil)
  signal(wrong-type-argument (ein:$kernelspec nil))
  ob-ein--initiate-session("127.0.0.1" "python-for-finance" #f(compiled-function (notebook) #<bytecode 0x46ecc7d>))
  ob-ein--execute-body("import sys\nsys.executable" ((:colname-names) (:rowname-names) (:result-params "replace" "drawer") (:result-type . value) (:results . "replace drawer") (:exports . "code") (:session . "none") (:cache . "no") (:noweb . "no") (:hlines . "no") (:tangle . "no") (:kernelspec . "python-for-finance")) nil)
  (let* ((parser (quote org-babel-variable-assignments:python)) (assignments (if (fboundp parser) (funcall (symbol-function parser) params) (ein:log (quote verbose) "%s: No suitable ob-%s module" (concat "org-babel-execute:" "ein-python") (quote python)) nil))) (ob-ein--execute-body body params assignments))
  org-babel-execute:ein-python("import sys\nsys.executable" ((:colname-names) (:rowname-names) (:result-params "replace" "drawer") (:result-type . value) (:results . "replace drawer") (:exports . "code") (:session . "none") (:cache . "no") (:noweb . "no") (:hlines . "no") (:tangle . "no") (:kernelspec . "python-for-finance")))
  org-babel-execute-src-block(nil ("ein-python" "import sys\nsys.executable" ((:colname-names) (:rowname-names) (:result-params "drawer" "replace") (:result-type . value) (:results . "drawer replace") (:exports . "code") (:kernelspec . "python-for-finance") (:tangle . "no") (:hlines . "no") (:noweb . "no") (:cache . "no") (:session . "none")) "" "test-naming-src-block" 212305 "(ref:%s)"))
  org-ctrl-c-ctrl-c(nil)
  funcall-interactively(org-ctrl-c-ctrl-c nil)
  call-interactively(org-ctrl-c-ctrl-c nil nil)
  command-execute(org-ctrl-c-ctrl-c)

[dickmao]

Please reopen if this is still an issue.