poetry in org-mode babel

[oatmealm]

I'm having difficulties getting python blocks to execute with a virtual environment activated. My setup, in doom emacs, seems to be fully functional with poetry.el otherwise, including lsp. The org file is in the same directory with the python code.

When I look at sys.path I see this:

#+property: header-args :session default :results output :exports both

#+BEGIN_SRC python
import sys
from credentials import consumer_key, consumer_secret

print(sys.path)
#+END_SRC

#+RESULTS:
: ['', '/usr/lib64/python38.zip', '/usr/lib64/python3.8', '/usr/lib64/python3.8/lib-dynload', '/home/uri/.local/lib/python3.8/site-packages', '/usr/local/lib/python3.8/site-packages', '/usr/lib64/python3.8/site-packages', '/usr/lib/python3.8/site-packages']

[galaunay]

I gave a quick try to your snippet and it works fine for me.

The only thing is that I had to restart the babel session (the one you named 'default').
If the session is started outside of the poetry virtualenv, it stays that way until you restart it.
Maybe the problem you are experiencing could come from that ?

[Ziip-dev]

I have a very similar question :)
My plan was:

• create a poetry project in a version controlled directory
• literate program in an org file (within my org roam directory)
• run source blocks within the poetry virtual env to test my code
• tangle everything to .py files in the project directory

Is this feasible? I have not figured it out yet (specifically the third point)

[Ziip-dev]

I have figured this out, in case some people are interested in the process here is a link to the reddit question for more details.
In summary:

* create a poetry project in a version controlled directory

This is the easy part, I just used basic poetry and git commands (or poetry.el and magit at your convenience).

* literate program in an org file

With babel functionalities, again, pretty straight forward with the documentation.

* run source blocks within the poetry virtual env to test my code

The trickiest part: a session must first be spawned in the corresponding virtual env with:

#+BEGIN_SRC elisp :results silent :session poetry_virtual_env
(pyvenv-activate "~/.cache/pypoetry/virtualenvs/my-poetry-virtual-env-xUtoYcEX-py3.7/")
#+END_SRC

Then following python blocks will execute in this virtual env session:

#+BEGIN_SRC python :results output :session poetry_virtual_env
import sys
print(sys.executable)
#+END_SRC

#+RESULTS:
: ~/.cache/pypoetry/virtualenvs/my-poetry-virtual-env-xUtoYcEX-py3.7/bin/python3

* tangle everything to .py files in the project directory

Tangle deletes the targeted file by default for each new tangled block. I found this excellent stackexchange answer which appends different blocks using noweb-ref before tangling. Very elegant :)
Here is a stripped down example:

#+BEGIN_SRC shell :noweb yes :exports none :mkdirp yes :tangle /tmp/accumulated.sh
<<accumulated>>
#+END_SRC

#+BEGIN_SRC shell :noweb-ref accumulated
echo "Hello"
#+END_SRC

#+BEGIN_SRC shell :noweb-ref accumulated
echo "World"
#+END_SRC

Now I can dev in org files and use literate programming functionalities while being able to test the code in the foreign virtual environment with the right dependencies before tangling everything in its corresponding .py file in the project directory.
Isn't that neat? 😁

[galaunay]

Nice !
Thanks for giving us feedback.

If having to write the entire virtualenv path annoys you, this block :

#+BEGIN_SRC elisp :results silent :session poetry_virtual_env
(pyvenv-activate "~/.cache/pypoetry/virtualenvs/my-poetry-virtual-env-xUtoYcEX-py3.7/")
#+END_SRC

could be replaced with this simpler one:

#+BEGIN_SRC elisp :results silent :session poetry_virtual_env
(poetry-venv-workon)
#+END_SRC

It will select the adequate virtualenv automatically.

Maybe even simpler, you could use property lines and just add this line at the top of your org file:

# -*- eval: (poetry-venv-workon); -*-

This will automatically activate the poetry virtualenv when opening your org file.

[Ziip-dev]

Very interesting, thank you for the tips!
How does it work if my org file is in a different location than the poetry project?

I also noticed that I don't need to define a session for the code block activating the virtual env: simply running (pyvenv-activate) in my org file activates the right virtual env and all python blocks execute in this env afterward. Could you please provide some insights on the question? :)