Re: [O] Mixing Python2 and Python3 blocks in one file

[William Henney]

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

[Ken Mankoff]

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

[William Henney]

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

[Ken Mankoff]

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

[William Henney]

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

[Ken Mankoff]

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

[Karl Voit]

* 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

[Thomas S. Dye]

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

[William Henney]

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

[John Kitchin]

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

[Karl Voit]

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

[William Henney]

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]

* 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

[Karl Voit]

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