Re: [O] Mixing Python2 and Python3 blocks in one file
On Thu, May 19, 2016 at 2:32 PM, Ken Mankoff wrote: > > On 2016-05-19 at 15:21, William Henney wrote: > > I think Elpy works fine with conda environments - you just have to > > call pyvenv-activate with the desired path. > > Yes, I have discovered that since I sent my email. > > > You have inspired me to try and automate this for org source blocks > > (see org snippets below). It is a bit clunky, but I got it to work. > > Let me know what you think, and any stylistic corrections are welcome > > (my lisp skills are sadly lacking). > > Better than my lisp. It looks good, but I like to keep my virtual envs in > the folder where the work happens. That is, I create them with =conda env > create -y -p ./pyenv=. I think this means your code below will fail because > it is looking for an =/envs/= folder. However, my method allows all virtual > environments to always have the same name, which could make the code (and > testing for the existence of that folder) easier. > > Yes, that’s right. You can just edit the part that says (string-match "/envs/" venv) and change "/envs/" to a regex that matches the way you name your environments. For instance, just the literal string "pyenv" should work. Or, even better, "env" would match both your convention and the standard location. > > + One thing we have to remember is to install the elpy python package > > and dependencies in each virtual environment. For instance: > > This can also be handled by =~./condarc= and the default packages > installed whenever a virtual environment is created. > > That's good to know - thanks Will > -k. > -- Dr William Henney, Instituto de Radioastronomía y Astrofísica, Universidad Nacional Autónoma de México, Campus Morelia
Re: [O] Mixing Python2 and Python3 blocks in one file
On 2016-05-19 at 15:21, William Henney wrote: > I think Elpy works fine with conda environments - you just have to > call pyvenv-activate with the desired path. Yes, I have discovered that since I sent my email. > You have inspired me to try and automate this for org source blocks > (see org snippets below). It is a bit clunky, but I got it to work. > Let me know what you think, and any stylistic corrections are welcome > (my lisp skills are sadly lacking). Better than my lisp. It looks good, but I like to keep my virtual envs in the folder where the work happens. That is, I create them with =conda env create -y -p ./pyenv=. I think this means your code below will fail because it is looking for an =/envs/= folder. However, my method allows all virtual environments to always have the same name, which could make the code (and testing for the existence of that folder) easier. > + One thing we have to remember is to install the elpy python package > and dependencies in each virtual environment. For instance: This can also be handled by =~./condarc= and the default packages installed whenever a virtual environment is created. -k.
Re: [O] Mixing Python2 and Python3 blocks in one file
On Thu, May 19, 2016 at 8:18 AM, Ken Mankoff wrote: > > Thanks for the example. This makes conda + Org work better than it has for > me in the past. Unfortunately, one major issues is editing and running code > outside of Org via (org-edit-special). Perhaps elpy will support conda > environments soon. > > I think Elpy works fine with conda environments - you just have to call pyvenv-activate with the desired path. You have inspired me to try and automate this for org source blocks (see org snippets below). It is a bit clunky, but I got it to work. Let me know what you think, and any stylistic corrections are welcome (my lisp skills are sadly lacking). * Automating Elpy virtual env configuration in babel source editing buffer + This function will automatically activate the virtual environment that corresponds to the current python executable path + It should be a harmless no-op if we are not in a python buffer #+BEGIN_SRC emacs-lisp (defun wjh/elpy-pyvenv-activate-from-babel-info (info) "Activate relevant conda virtual env in Babel source editing buffer. The :python source block parameter is inspected to determine the venv." (let* ((python-command (or (cdr (assoc :python (nth 2 info))) org-babel-python-command)) (venv (replace-regexp-in-string "/bin/python$" "" python-command))) (when (string-match "/envs/" venv) (pyvenv-activate (expand-file-name venv) #+END_SRC + Then we need to make sure it is run whenever we edit a babel source block by doing something like =(wjh/elpy-pyvenv-activate-from-babel-info org-src--babel-info)=, and also to do =(pyvenv-deactivate)= when we leave + Unfortunately, there are no actual hooks that I can find for =org-edit-src-code= or =org-edit-src-exit= + For the activation part we can co-opt the =org-babel-edit-prep:python= function: #+BEGIN_SRC emacs-lisp (defun org-babel-edit-prep:python (info) (wjh/elpy-pyvenv-activate-from-babel-info info)) #+END_SRC + Although this will break if =ob-python.el= decides to define =org-babel-edit-prep:python= one day + For the deactivation part, I can't see any other way than to use advice #+BEGIN_SRC emacs-lisp (advice-add 'org-edit-src-exit :after #'pyvenv-deactivate) #+END_SRC + One thing we have to remember is to install the elpy python package and dependencies in each virtual environment. For instance: #+BEGIN_SRC sh source activate myenv pip install elpy rope_py3k importmagic autopep8 yapf jedi #+END_SRC -- Dr William Henney, Instituto de Radioastronomía y Astrofísica, Universidad Nacional Autónoma de México, Campus Morelia
Re: [O] Mixing Python2 and Python3 blocks in one file
Hi Will, Thanks for the example. This makes conda + Org work better than it has for me in the past. Unfortunately, one major issues is editing and running code outside of Org via (org-edit-special). Perhaps elpy will support conda environments soon. On 2016-05-18 at 23:37, William Henney wrote: > #+BEGIN_SRC python :python ~/anaconda/envs/myenv/bin/python :results > verbatim > import sys > return sys.path > #+END_SRC Anyway, for those of us using IPython, the following also works: #+BEGIN_SRC python :python ./myenv/bin/ipython --pylab=osx --pdb --nosep --classic --no-banner --no-confirm-exit print(np.__version__) #+END_SRC -k.
Re: [O] Mixing Python2 and Python3 blocks in one file
Hi Ken, On Wed, May 18, 2016 at 8:45 AM, Ken Mankoff wrote: On 2016-05-17 at 21:19, William Henney wrote: > > Why is the :python parameter insufficient for your needs? You can also > > use it for different virtual environments > > Can you clarify how to do this? Does it work with conda environments too? > Yes, you just have to specify ~/anaconda/envs/NAME_OF_ENV/bin/python as the name of the interpreter I gave a conda example in my first message to this thread, but here is another one. In the shell, I just made a new environment: $ condo create --name myenv And now, I can test it in an org file: #+BEGIN_SRC python :python ~/anaconda/envs/myenv/bin/python :results verbatim import sys return sys.path #+END_SRC #+RESULTS: : ['', '/Users/will/anaconda/envs/myenv/lib/python35.zip', '/Users/will/anaconda/envs/myenv/lib/python3.5', '/Users/will/anaconda/envs/myenv/lib/python3.5/plat-darwin', '/Users/will/anaconda/envs/myenv/lib/python3.5/lib-dynload', '/Users/will/anaconda/envs/myenv/lib/python3.5/site-packages', '/Users/will/anaconda/envs/myenv/lib/python3.5/site-packages/setuptools-20.7.0-py3.5.egg'] Note that this is not /exactly/ equivalent to doing “source activate myenv” in a terminal shell since it does not run any activation/deactivation scripts that you might have put in the virtual environment. But personally I never use that feature Will -- Dr William Henney, Instituto de Radioastronomía y Astrofísica, Universidad Nacional Autónoma de México, Campus Morelia
Re: [O] Mixing Python2 and Python3 blocks in one file
Hi Will, On 2016-05-17 at 21:19, William Henney wrote: > Why is the :python parameter insufficient for your needs? You can also > use it for different virtual environments Can you clarify how to do this? Does it work with conda environments too? Thanks, -k.
Re: [O] Mixing Python2 and Python3 blocks in one file
* Thomas S. Dye wrote: > > William Henney writes: >> >> It is documented at >> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html > > As of a few hours ago, when I added it. It probably wasn't there when > Karl looked. Thank you very much Thomas! I can not appreciate documentation improvements too much ;-) -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: > get Memacs from https://github.com/novoid/Memacs < https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
Re: [O] Mixing Python2 and Python3 blocks in one file
William Henney writes: >> Cool, I did not find this parameter yet. >> >> Is this undocumented? http://orgmode.org/org.html does not contain >> the string ":python:" and >> http://orgmode.org/org.html#Language_002dspecific-header-arguments >> also does not mention this parameter. >> >> > It is documented at > http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html As of a few hours ago, when I added it. It probably wasn't there when Karl looked. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Mixing Python2 and Python3 blocks in one file
Hi Karl On Tue, May 17, 2016 at 9:54 AM, Karl Voit wrote: > Hi William > > * William Henney wrote: > > > > On Sun, May 8, 2016 at 3:31 AM, Karl Voit wrote: > > > > Python2 and Python3 are two different languages. Unfortunately, > >> Org-mode only uses ~#+BEGIN_SRC python~ for both and uses > >> python-shell-interpreter to choose/switch the compiler. > >> > >> Shouldn't Org-mode introduce ~#+BEGIN_SRC python2~ and ~#+BEGIN_SRC > >> python3~ to solve this issue in a clean way? > >> > >> ~#+BEGIN_SRC python~ can still default to python2. > >> > > You can use the :python header argument to the source block, which allows > > you to specify the path to the python interpreter: > > > > #+BEGIN_SRC python :python /Users/will/anaconda/envs/py27/bin/python > > Cool, I did not find this parameter yet. > > Is this undocumented? http://orgmode.org/org.html does not contain > the string ":python:" and > http://orgmode.org/org.html#Language_002dspecific-header-arguments > also does not mention this parameter. > > It is documented at http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html You are right that it would be better if the language-specific babel documentation were better integrated in the general org info file. But I suppose nobody has been sufficiently motivated to do it yet > > Also see original discussion at > > https://lists.gnu.org/archive/html/emacs-orgmode/2014-04/msg01042.html > > Most interesting to me, thank you. > > With the parameter above as a workaround, I can accomplish the > things I want to do for now. However, I still do think that Python2 > and Python3 as different languages demand different block > identifiers. > > #+BEGIN_SRC python -> defaults to the default python interpreter > #+BEGIN_SRC python2 -> uses Python2 > #+BEGIN_SRC python3 -> uses Python3 > > Don't you think? > > To be honest, I disagree that we need different block identifiers. Python is hardly the only language to have gone through multiple major versions, and I don’t think a proliferation of org-babel languages is the answer. What about C11 vs C99, etc? I guess a good rule of thumb would be: do the two versions use the same major mode in emacs? Why is the :python parameter insufficient for your needs? You can also use it for different virtual environments Cheers Will > -- > mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: >> get Memacs from https://github.com/novoid/Memacs < > > https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on > github > > > -- Dr William Henney, Instituto de Radioastronomía y Astrofísica, Universidad Nacional Autónoma de México, Campus Morelia
Re: [O] Mixing Python2 and Python3 blocks in one file
You can hack this to work: #+BEGIN_SRC emacs-lisp (defun org-babel-execute:python2 (body params) (let ((org-babel-python-command "/Users/jkitchin/Library/Enthought/Canopy_64bit/User/bin/python2")) (org-babel-execute:python body params))) #+END_SRC #+BEGIN_SRC python2 print 'Hello' #+END_SRC #+RESULTS: : Hello One issue though is no font-lock in the source block. I think it uses the language to set the mode. Karl Voit writes: > Hi William > > * William Henney wrote: >> >> On Sun, May 8, 2016 at 3:31 AM, Karl Voit wrote: >> >> Python2 and Python3 are two different languages. Unfortunately, >>> Org-mode only uses ~#+BEGIN_SRC python~ for both and uses >>> python-shell-interpreter to choose/switch the compiler. >>> >>> Shouldn't Org-mode introduce ~#+BEGIN_SRC python2~ and ~#+BEGIN_SRC >>> python3~ to solve this issue in a clean way? >>> >>> ~#+BEGIN_SRC python~ can still default to python2. >>> >> You can use the :python header argument to the source block, which allows >> you to specify the path to the python interpreter: >> >> #+BEGIN_SRC python :python /Users/will/anaconda/envs/py27/bin/python > > Cool, I did not find this parameter yet. > > Is this undocumented? http://orgmode.org/org.html does not contain > the string ":python:" and > http://orgmode.org/org.html#Language_002dspecific-header-arguments > also does not mention this parameter. > >> Also see original discussion at >> https://lists.gnu.org/archive/html/emacs-orgmode/2014-04/msg01042.html > > Most interesting to me, thank you. > > With the parameter above as a workaround, I can accomplish the > things I want to do for now. However, I still do think that Python2 > and Python3 as different languages demand different block > identifiers. > > #+BEGIN_SRC python -> defaults to the default python interpreter > #+BEGIN_SRC python2 -> uses Python2 > #+BEGIN_SRC python3 -> uses Python3 > > Don't you think? -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Mixing Python2 and Python3 blocks in one file
Hi William * William Henney wrote: > > On Sun, May 8, 2016 at 3:31 AM, Karl Voit wrote: > > Python2 and Python3 are two different languages. Unfortunately, >> Org-mode only uses ~#+BEGIN_SRC python~ for both and uses >> python-shell-interpreter to choose/switch the compiler. >> >> Shouldn't Org-mode introduce ~#+BEGIN_SRC python2~ and ~#+BEGIN_SRC >> python3~ to solve this issue in a clean way? >> >> ~#+BEGIN_SRC python~ can still default to python2. >> > You can use the :python header argument to the source block, which allows > you to specify the path to the python interpreter: > > #+BEGIN_SRC python :python /Users/will/anaconda/envs/py27/bin/python Cool, I did not find this parameter yet. Is this undocumented? http://orgmode.org/org.html does not contain the string ":python:" and http://orgmode.org/org.html#Language_002dspecific-header-arguments also does not mention this parameter. > Also see original discussion at > https://lists.gnu.org/archive/html/emacs-orgmode/2014-04/msg01042.html Most interesting to me, thank you. With the parameter above as a workaround, I can accomplish the things I want to do for now. However, I still do think that Python2 and Python3 as different languages demand different block identifiers. #+BEGIN_SRC python -> defaults to the default python interpreter #+BEGIN_SRC python2 -> uses Python2 #+BEGIN_SRC python3 -> uses Python3 Don't you think? -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: > get Memacs from https://github.com/novoid/Memacs < https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
Re: [O] Mixing Python2 and Python3 blocks in one file
Hi Karl On Sun, May 8, 2016 at 3:31 AM, Karl Voit wrote: Python2 and Python3 are two different languages. Unfortunately, > Org-mode only uses ~#+BEGIN_SRC python~ for both and uses > python-shell-interpreter to choose/switch the compiler. > > Shouldn't Org-mode introduce ~#+BEGIN_SRC python2~ and ~#+BEGIN_SRC > python3~ to solve this issue in a clean way? > > ~#+BEGIN_SRC python~ can still default to python2. > > > You can use the :python header argument to the source block, which allows you to specify the path to the python interpreter: — BEGIN EXAMPLE * Default python version #+name: check-python-version #+BEGIN_SRC python import sys return sys.version #+END_SRC #+RESULTS: check-python-version : 3.4.4 |Anaconda 2.5.0 (x86_64)| (default, Jan 9 2016, 17:30:09) : [GCC 4.2.1 (Apple Inc. build 5577)] This is the control experiment. * Custom python version #+BEGIN_SRC python :python /Users/will/anaconda/envs/py27/bin/python import sys return sys.version #+END_SRC #+RESULTS: : 2.7.11 |Continuum Analytics, Inc.| (default, Dec 6 2015, 18:57:58) : [GCC 4.2.1 (Apple Inc. build 5577)] — END EXAMPLE Also see original discussion at https://lists.gnu.org/archive/html/emacs-orgmode/2014-04/msg01042.html Will > I only found those sources/solutions: > > http://thread.gmane.org/gmane.emacs.orgmode/47867 > ... file-variables to choose interpretor > > http://thread.gmane.org/gmane.emacs.orgmode/47867 > ... workaround with #+srcname (I don't get yet) > > > -- > mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: >> get Memacs from https://github.com/novoid/Memacs < > > https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on > github > > > -- Dr William Henney, Instituto de Radioastronomía y Astrofísica, Universidad Nacional Autónoma de México, Campus Morelia
Re: [O] Mixing Python2 and Python3 blocks in one file
* Karl Voit wrote: > Hi! > > Python2 and Python3 are two different languages. Unfortunately, > Org-mode only uses ~#+BEGIN_SRC python~ for both and uses > python-shell-interpreter to choose/switch the compiler. > > Shouldn't Org-mode introduce ~#+BEGIN_SRC python2~ and ~#+BEGIN_SRC > python3~ to solve this issue in a clean way? > > ~#+BEGIN_SRC python~ can still default to python2. > > > I only found those sources/solutions: Correct links: http://article.gmane.org/gmane.emacs.orgmode/47878 > ... file-variables to choose interpretor http://article.gmane.org/gmane.emacs.orgmode/47955 > ... workaround with #+srcname (I don't get yet) -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: > get Memacs from https://github.com/novoid/Memacs < https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
[O] Mixing Python2 and Python3 blocks in one file
Hi! Python2 and Python3 are two different languages. Unfortunately, Org-mode only uses ~#+BEGIN_SRC python~ for both and uses python-shell-interpreter to choose/switch the compiler. Shouldn't Org-mode introduce ~#+BEGIN_SRC python2~ and ~#+BEGIN_SRC python3~ to solve this issue in a clean way? ~#+BEGIN_SRC python~ can still default to python2. I only found those sources/solutions: http://thread.gmane.org/gmane.emacs.orgmode/47867 ... file-variables to choose interpretor http://thread.gmane.org/gmane.emacs.orgmode/47867 ... workaround with #+srcname (I don't get yet) -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: > get Memacs from https://github.com/novoid/Memacs < https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github