[Proposal] Source Blocks with Post-Extensions

[Proposal] Source Blocks with Post-Extensions

[Dmitrii Korobeinikov]

[-- Attachment #1.1: Type: text/plain, Size: 2140 bytes --]

For your convenience, I have attached this e-mail as an org-mode file.

When I write several source blocks, which depend on one another, I tend to
debug them one by one.

So, I write this function and test it:

#+NAME: square
#+BEGIN_SRC python
    square = lambda x: x * x
    return square(5)
#+END_SRC

#+RESULTS: square
: 25

After I see that the test is successful, I write this client function:

#+BEGIN_SRC python :noweb yes
    <<square>>
    return 5 + square(5)
#+END_SRC

#+RESULTS:
: 25

And here, to get the correct result, I have to remove the ~return
square(5)~ line in ~<<square>>~.
But I don't want to lose testing!
So I find nothing better to do than to seperate the source block:

#+NAME: square-1
#+BEGIN_SRC python
    square = lambda x: x * x
#+END_SRC

And, by the way, there was no error/warning that I have just redefined
~<<square>>~,
so, for the test-snippet below to work, I renamed it to ~<<square-1>>~.
I think the org-mode team is aware of it, but anyway:

- [ ] no error checking of the description of a code block.

#+NAME: square-1-tester
#+BEGIN_SRC python :noweb yes
  <<square-1>>
  return square(5)
#+END_SRC

#+RESULTS: square-1-tester
: 25

- [ ] For every such source block used for testing purposes, you have to
repeat the inclusion statement and part of the name, which is cumbersome.

A fair solution is maybe to extend the block like this:

#+NAME: square-1
#+BEGIN_SRC python
  square = lambda x: x * x
#+END_SRC
  return square(5)
#+END_SRC_TEST

When I call this individually, the test part would run, but when I :noweb
it in another block, the test part would be ommited.

As an extension of this idea, it could be useful to have several test
attachments like this, each producing its own result. Maybe, the TEST part
could as well be ommited. Custom names are also an option:

#+NAME: square-multiple
#+BEGIN_SRC python
  square = lambda x: x * x
#+END_SRC
  return square(5)
#+END_SRC NAME: ext_1
  return square(10)
#+END_SRC NAME: ext_2

#+RESULTS: square-multiple-ext-1
: 25

#+RESULTS: square-multiple-ext-2
: 100

Overall, these techniques should reduce noise and increase usability.

[-- Attachment #1.2: Type: text/html, Size: 3204 bytes --]

[-- Attachment #2: org-test-suite.org --]
[-- Type: application/octet-stream, Size: 2182 bytes --]

#+TITLE: [Proposal] Source Blocks with Post-Extensions
#+AUTHOR: Dmitrii Korobeinikov
#+EMAIL: dim1212k@gmail.com

When I write several source blocks, which depend on one another, I tend to debug them one by one.

So, I write this function and test it:

#+NAME: square
#+BEGIN_SRC python
    square = lambda x: x * x
    return square(5)
#+END_SRC

#+RESULTS: square
: 25

After I see that the test is successful, I write this client function:

#+BEGIN_SRC python :noweb yes
    <<square>>
    return 5 + square(5)
#+END_SRC

#+RESULTS:
: 25

And here, to get the correct result, I have to remove the ~return square(5)~ line in ~<<square>>~.
But I don't want to lose testing!
So I find nothing better to do than to seperate the source block:

#+NAME: square-1
#+BEGIN_SRC python
    square = lambda x: x * x
#+END_SRC

And, by the way, there was no error/warning that I have just redefined ~<<square>>~,
so, for the test-snippet below to work, I renamed it to ~<<square-1>>~.
I think the org-mode team is aware of it, but anyway:

- [ ] no error checking of the description of a code block.

#+NAME: square-1-tester
#+BEGIN_SRC python :noweb yes
  <<square-1>>
  return square(5)
#+END_SRC

#+RESULTS: square-1-tester
: 25

- [ ] For every such source block used for testing purposes, you have to repeat the inclusion statement and part of the name, which is cumbersome.

A fair solution is maybe extend the block like this:

#+NAME: square-1
#+BEGIN_SRC python
  square = lambda x: x * x
#+END_SRC
  return square(5)
#+END_SRC_TEST

When I call this individually, the test part would run, but when I :noweb it in another block, the test part would be ommited.

As an extension of this idea, it could be useful to have several test attachments like this, each producing its own result. Maybe, the TEST part could as well be ommited. Custom names are also an option:

#+NAME: square-multiple
#+BEGIN_SRC python
  square = lambda x: x * x
#+END_SRC
  return square(5)
#+END_SRC NAME: ext_1 
  return square(10)
#+END_SRC NAME: ext_2 

#+RESULTS: square-multiple-ext-1
: 25

#+RESULTS: square-multiple-ext-2
: 100

Overall, these techniques should reduce noise and increase usability.

Re: [Proposal] Source Blocks with Post-Extensions

[Berry, Charles]

It looks like you want the :epilogue header argument. See inline.

> On Apr 22, 2019, at 2:00 AM, Dmitrii Korobeinikov <dim1212k@gmail.com> wrote:
> 
> When I write several source blocks, which depend on one another, I tend to debug them one by one.
> 
> So, I write this function and test it:
> 
> #+NAME: square
> #+BEGIN_SRC python
>     square = lambda x: x * x
>     return square(5)
> #+END_SRC
> 
> #+RESULTS: square
> : 25
> 


Equivalently, you could run this:

#+NAME: square
#+BEGIN_SRC python :epilogue  return square(5)
    square = lambda x: x * x
#+END_SRC



> After I see that the test is successful, I write this client function:
> 
> #+BEGIN_SRC python :noweb yes
>     <<square>>
>     return 5 + square(5)
> #+END_SRC
> 
> #+RESULTS:
> : 25
> 
> And here, to get the correct result, I have to remove the ~return square(5)~ line in ~<<square>>~.
> But I don't want to lose testing!
> S

With my version of `square`, the epilogue is not included. 

So it works as you want it to.

HTH,

Chuck

Re: [Proposal] Source Blocks with Post-Extensions

[Dmitrii Korobeinikov]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

Thank you!
That's a handy technique and it does help.
As I understand, there's no way to extend that to multiple lines?
One-liners for tests are enough sometimes, but not always.
For those cases, it is cumbersome to split as well.

пн, 22 апр. 2019 г. в 22:51, Berry, Charles <ccberry@ucsd.edu>:

> It looks like you want the :epilogue header argument. See inline.
>
> > On Apr 22, 2019, at 2:00 AM, Dmitrii Korobeinikov <dim1212k@gmail.com>
> wrote:
> >
> > When I write several source blocks, which depend on one another, I tend
> to debug them one by one.
> >
> > So, I write this function and test it:
> >
> > #+NAME: square
> > #+BEGIN_SRC python
> >     square = lambda x: x * x
> >     return square(5)
> > #+END_SRC
> >
> > #+RESULTS: square
> > : 25
> >
>
>
> Equivalently, you could run this:
>
> #+NAME: square
> #+BEGIN_SRC python :epilogue  return square(5)
>     square = lambda x: x * x
> #+END_SRC
>
>
>
> > After I see that the test is successful, I write this client function:
> >
> > #+BEGIN_SRC python :noweb yes
> >     <<square>>
> >     return 5 + square(5)
> > #+END_SRC
> >
> > #+RESULTS:
> > : 25
> >
> > And here, to get the correct result, I have to remove the ~return
> square(5)~ line in ~<<square>>~.
> > But I don't want to lose testing!
> > S
>
> With my version of `square`, the epilogue is not included.
>
> So it works as you want it to.
>
> HTH,
>
> Chuck
>
>
>

[-- Attachment #2: Type: text/html, Size: 2166 bytes --]

Re: [Proposal] Source Blocks with Post-Extensions

[Berry, Charles]

> On Apr 22, 2019, at 10:15 AM, Dmitrii Korobeinikov <dim1212k@gmail.com> wrote:
> 
> Thank you!
> That's a handy technique and it does help.
> As I understand, there's no way to extend that to multiple lines?

AFAICS, no there is no way to split the :epilogue arg to multiple lines.

Of course, you can always follow a src block that provides a function with another src block that imports the code via noweb and then tests the function with as many lines of code as you need. 

Chuck

Re: [Proposal] Source Blocks with Post-Extensions

[Tim Cross]

YMMV, but personally, I think the real problem here is combining your
tests with your definition. i.e. square = lambda x: x * x is your real
code block while the return line is really just part of
testing/debugging and should not be in your definition block.

Tests are very important, but I find they 'clutter' the code and make it
harder to read/think about the core functionality - especially after
leaving and returning some time later to worik on the core code.

My approach is to keep the code blocks as 'pure' as possible and put all
the tests in a separate section of the org file. It does make code test
coverage a bit more challenging because you don't have the two 'side by
side', but I find that is offset by the increased clarity with the main
code.

just an alternative view ....

Dmitrii Korobeinikov <dim1212k@gmail.com> writes:

> For your convenience, I have attached this e-mail as an org-mode file.
>
> When I write several source blocks, which depend on one another, I tend to
> debug them one by one.
>
> So, I write this function and test it:
>
> #+NAME: square
> #+BEGIN_SRC python
>     square = lambda x: x * x
>     return square(5)
> #+END_SRC
>
> #+RESULTS: square
> : 25
>
> After I see that the test is successful, I write this client function:
>
> #+BEGIN_SRC python :noweb yes
>     <<square>>
>     return 5 + square(5)
> #+END_SRC
>
> #+RESULTS:
> : 25
>
> And here, to get the correct result, I have to remove the ~return
> square(5)~ line in ~<<square>>~.
> But I don't want to lose testing!
> So I find nothing better to do than to seperate the source block:
>
> #+NAME: square-1
> #+BEGIN_SRC python
>     square = lambda x: x * x
> #+END_SRC
>
> And, by the way, there was no error/warning that I have just redefined
> ~<<square>>~,
> so, for the test-snippet below to work, I renamed it to ~<<square-1>>~.
> I think the org-mode team is aware of it, but anyway:
>
> - [ ] no error checking of the description of a code block.
>
> #+NAME: square-1-tester
> #+BEGIN_SRC python :noweb yes
>   <<square-1>>
>   return square(5)
> #+END_SRC
>
> #+RESULTS: square-1-tester
> : 25
>
> - [ ] For every such source block used for testing purposes, you have to
> repeat the inclusion statement and part of the name, which is cumbersome.
>
> A fair solution is maybe to extend the block like this:
>
> #+NAME: square-1
> #+BEGIN_SRC python
>   square = lambda x: x * x
> #+END_SRC
>   return square(5)
> #+END_SRC_TEST
>
> When I call this individually, the test part would run, but when I :noweb
> it in another block, the test part would be ommited.
>
> As an extension of this idea, it could be useful to have several test
> attachments like this, each producing its own result. Maybe, the TEST part
> could as well be ommited. Custom names are also an option:
>
> #+NAME: square-multiple
> #+BEGIN_SRC python
>   square = lambda x: x * x
> #+END_SRC
>   return square(5)
> #+END_SRC NAME: ext_1
>   return square(10)
> #+END_SRC NAME: ext_2
>
> #+RESULTS: square-multiple-ext-1
> : 25
>
> #+RESULTS: square-multiple-ext-2
> : 100
>
> Overall, these techniques should reduce noise and increase usability.


-- 
Tim Cross

Re: [Proposal] Source Blocks with Post-Extensions

[Dmitrii Korobeinikov]

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

Sorry for not answering these two days.

You are right, that's an option.
But I just don't think that's the best possible one - for usability.

Introducing this would imply architectural decisions, so it might not be
immediately clear if it's right or not.
Especially that the improvement might not seem that big.
So, I understand that.

I have proposed buffer lenses today and they seem like something that can
solve the issue from the user side. Hopefully they will get some traction.

пн, 22 апр. 2019 г. в 23:31, Berry, Charles <ccberry@ucsd.edu>:

>
>
> > On Apr 22, 2019, at 10:15 AM, Dmitrii Korobeinikov <dim1212k@gmail.com>
> wrote:
> >
> > Thank you!
> > That's a handy technique and it does help.
> > As I understand, there's no way to extend that to multiple lines?
>
> AFAICS, no there is no way to split the :epilogue arg to multiple lines.
>
> Of course, you can always follow a src block that provides a function with
> another src block that imports the code via noweb and then tests the
> function with as many lines of code as you need.
>
> Chuck
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1625 bytes --]

Re: [Proposal] Source Blocks with Post-Extensions

[Martin Alsinet]

[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]

Dmitrii,

I use a different approach, where I tangle the source into files in modules
and then I import those modules from other blocks.
This allows me to organize my document with different sections for the code
and its tests, which then get exported into their corresponding files.


* Square Function

This function receives a number and returns its square

#+BEGIN_SRC python :tangle ./utils/math.py :mkdirp yes
def square(x):
    return x * x
#+END_SRC

** __init__.py (module setup)

#+begin_src python :tangle ./utils/__init__.py :mkdirp yes
from utils.math import square

#+end_src

** Test cases

1. The square of five should be 25
2. The square of zero should be 0
3. The square of a negative number should be positive

#+BEGIN_SRC python :tangle ./utils/test_square.py :mkdirp yes
from utils.math import square

def test_square_of_five():
    assert square(5) == 25

def test_square_of_zero():
    assert square(0) == 0

def test_square_of_negative():
    assert square(-5) > 0
#+END_SRC

*** Run tests

#+begin_src sh :results output raw
pytest ./utils
#+end_src

#+RESULTS:
============================= test session starts
==============================
platform linux -- Python 3.7.3, pytest-4.6.3, py-1.8.0, pluggy-0.12.0
rootdir: /app
collected 3 items

utils/test_square.py ...
[100%]

=========================== 3 passed in 0.08 seconds
===========================






On Wed, Apr 24, 2019 at 2:19 PM Dmitrii Korobeinikov <dim1212k@gmail.com>
wrote:

> Sorry for not answering these two days.
>
> You are right, that's an option.
> But I just don't think that's the best possible one - for usability.
>
> Introducing this would imply architectural decisions, so it might not be
> immediately clear if it's right or not.
> Especially that the improvement might not seem that big.
> So, I understand that.
>
> I have proposed buffer lenses today and they seem like something that can
> solve the issue from the user side. Hopefully they will get some traction.
>
> пн, 22 апр. 2019 г. в 23:31, Berry, Charles <ccberry@ucsd.edu>:
>
>>
>>
>> > On Apr 22, 2019, at 10:15 AM, Dmitrii Korobeinikov <dim1212k@gmail.com>
>> wrote:
>> >
>> > Thank you!
>> > That's a handy technique and it does help.
>> > As I understand, there's no way to extend that to multiple lines?
>>
>> AFAICS, no there is no way to split the :epilogue arg to multiple lines.
>>
>> Of course, you can always follow a src block that provides a function
>> with another src block that imports the code via noweb and then tests the
>> function with as many lines of code as you need.
>>
>> Chuck
>>
>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 7912 bytes --]

Re: [Proposal] Source Blocks with Post-Extensions

[Dmitrii Korobeinikov]

[-- Attachment #1: Type: text/plain, Size: 3233 bytes --]

Dear Martin,

Your approach to test cases is quite valuable for more structured projects
and for automation. For something that's either quick&dirty or w/out much
architectural certainty to it, I would still prefer the handy one-liners.
Nonetheless, thanks for the example!

Best,
Dmitrii.

чт, 27 июн. 2019 г. в 04:09, Martin Alsinet <martin@alsinet.com.ar>:

> Dmitrii,
>
> I use a different approach, where I tangle the source into files in
> modules and then I import those modules from other blocks.
> This allows me to organize my document with different sections for the
> code and its tests, which then get exported into their corresponding files.
>
>
> * Square Function
>
> This function receives a number and returns its square
>
> #+BEGIN_SRC python :tangle ./utils/math.py :mkdirp yes
> def square(x):
>     return x * x
> #+END_SRC
>
> ** __init__.py (module setup)
>
> #+begin_src python :tangle ./utils/__init__.py :mkdirp yes
> from utils.math import square
>
> #+end_src
>
> ** Test cases
>
> 1. The square of five should be 25
> 2. The square of zero should be 0
> 3. The square of a negative number should be positive
>
> #+BEGIN_SRC python :tangle ./utils/test_square.py :mkdirp yes
> from utils.math import square
>
> def test_square_of_five():
>     assert square(5) == 25
>
> def test_square_of_zero():
>     assert square(0) == 0
>
> def test_square_of_negative():
>     assert square(-5) > 0
> #+END_SRC
>
> *** Run tests
>
> #+begin_src sh :results output raw
> pytest ./utils
> #+end_src
>
> #+RESULTS:
> ============================= test session starts
> ==============================
> platform linux -- Python 3.7.3, pytest-4.6.3, py-1.8.0, pluggy-0.12.0
> rootdir: /app
> collected 3 items
>
> utils/test_square.py ...
> [100%]
>
> =========================== 3 passed in 0.08 seconds
> ===========================
>
>
>
>
>
>
> On Wed, Apr 24, 2019 at 2:19 PM Dmitrii Korobeinikov <dim1212k@gmail.com>
> wrote:
>
>> Sorry for not answering these two days.
>>
>> You are right, that's an option.
>> But I just don't think that's the best possible one - for usability.
>>
>> Introducing this would imply architectural decisions, so it might not be
>> immediately clear if it's right or not.
>> Especially that the improvement might not seem that big.
>> So, I understand that.
>>
>> I have proposed buffer lenses today and they seem like something that can
>> solve the issue from the user side. Hopefully they will get some traction.
>>
>> пн, 22 апр. 2019 г. в 23:31, Berry, Charles <ccberry@ucsd.edu>:
>>
>>>
>>>
>>> > On Apr 22, 2019, at 10:15 AM, Dmitrii Korobeinikov <dim1212k@gmail.com>
>>> wrote:
>>> >
>>> > Thank you!
>>> > That's a handy technique and it does help.
>>> > As I understand, there's no way to extend that to multiple lines?
>>>
>>> AFAICS, no there is no way to split the :epilogue arg to multiple lines.
>>>
>>> Of course, you can always follow a src block that provides a function
>>> with another src block that imports the code via noweb and then tests the
>>> function with as many lines of code as you need.
>>>
>>> Chuck
>>>
>>>
>>>
>>>

[-- Attachment #2: Type: text/html, Size: 8543 bytes --]

Re: [Proposal] Source Blocks with Post-Extensions

[Ken Mankoff]

Hi Martin,

On 2019-06-26 at 18:09 -04, Martin Alsinet <martin@alsinet.com.ar> wrote...
> I use a different approach, where I tangle the source into files in
> modules and then I import those modules from other blocks. This allows
> me to organize my document with different sections for the code and
> its tests, which then get exported into their corresponding files.

Thanks for providing this pytest code below. It runs nicely because your tests pass. It does not run if a test fails. The shell block that runs pytest reports

Babel evaluation exited with code 1
Code block produced no output.

Do you have some way of capturing failed pytest tests in Org Babel?

Thanks,

  -k.
  
> * Square Function
>
> This function receives a number and returns its square
>
> #+BEGIN_SRC python :tangle ./utils/math.py :mkdirp yes
> def square(x):
>     return x * x
> #+END_SRC
>
> ** __init__.py (module setup)
>
> #+begin_src python :tangle ./utils/__init__.py :mkdirp yes
> from utils.math import square
>
> #+end_src
>
> ** Test cases
>
> 1. The square of five should be 25
> 2. The square of zero should be 0
> 3. The square of a negative number should be positive
>
> #+BEGIN_SRC python :tangle ./utils/test_square.py :mkdirp yes
> from utils.math import square
>
> def test_square_of_five():
>     assert square(5) == 25
>
> def test_square_of_zero():
>     assert square(0) == 0
>
> def test_square_of_negative():
>     assert square(-5) > 0
> #+END_SRC
>
> *** Run tests
>
> #+begin_src sh :results output raw
> pytest ./utils
> #+end_src
>
> #+RESULTS:
> ============================= test session starts
> ==============================
> platform linux -- Python 3.7.3, pytest-4.6.3, py-1.8.0, pluggy-0.12.0
> rootdir: /app
> collected 3 items
>
> utils/test_square.py ...
> [100%]
>
> =========================== 3 passed in 0.08 seconds
> ===========================
>
>

Re: [Proposal] Source Blocks with Post-Extensions

[Martin Alsinet]

[-- Attachment #1: Type: text/plain, Size: 2492 bytes --]

Ken,

I usually have a shell buffer nearby and go there to inspect the failed
tests when I get no output.
The problem is that shell blocks do not capture stderr. John Kitchin wrote
a blog post
<http://kitchingroup.cheme.cmu.edu/blog/2015/01/04/Redirecting-stderr-in-org-mode-shell-blocks/>
about this problem and provided a solution that may work for you, but I
have not tried it yet.

Martin

On Fri, Jul 26, 2019 at 7:02 AM Ken Mankoff <mankoff@gmail.com> wrote:

> Hi Martin,
>
> On 2019-06-26 at 18:09 -04, Martin Alsinet <martin@alsinet.com.ar>
> wrote...
> > I use a different approach, where I tangle the source into files in
> > modules and then I import those modules from other blocks. This allows
> > me to organize my document with different sections for the code and
> > its tests, which then get exported into their corresponding files.
>
> Thanks for providing this pytest code below. It runs nicely because your
> tests pass. It does not run if a test fails. The shell block that runs
> pytest reports
>
> Babel evaluation exited with code 1
> Code block produced no output.
>
> Do you have some way of capturing failed pytest tests in Org Babel?
>
> Thanks,
>
>   -k.
>
> > * Square Function
> >
> > This function receives a number and returns its square
> >
> > #+BEGIN_SRC python :tangle ./utils/math.py :mkdirp yes
> > def square(x):
> >     return x * x
> > #+END_SRC
> >
> > ** __init__.py (module setup)
> >
> > #+begin_src python :tangle ./utils/__init__.py :mkdirp yes
> > from utils.math import square
> >
> > #+end_src
> >
> > ** Test cases
> >
> > 1. The square of five should be 25
> > 2. The square of zero should be 0
> > 3. The square of a negative number should be positive
> >
> > #+BEGIN_SRC python :tangle ./utils/test_square.py :mkdirp yes
> > from utils.math import square
> >
> > def test_square_of_five():
> >     assert square(5) == 25
> >
> > def test_square_of_zero():
> >     assert square(0) == 0
> >
> > def test_square_of_negative():
> >     assert square(-5) > 0
> > #+END_SRC
> >
> > *** Run tests
> >
> > #+begin_src sh :results output raw
> > pytest ./utils
> > #+end_src
> >
> > #+RESULTS:
> > ============================= test session starts
> > ==============================
> > platform linux -- Python 3.7.3, pytest-4.6.3, py-1.8.0, pluggy-0.12.0
> > rootdir: /app
> > collected 3 items
> >
> > utils/test_square.py ...
> > [100%]
> >
> > =========================== 3 passed in 0.08 seconds
> > ===========================
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 3364 bytes --]

Re: [Proposal] Source Blocks with Post-Extensions

[Ken Mankoff]

On 2019-07-26 at 08:58 -04, Martin Alsinet <martin@alsinet.com.ar> wrote...
> I usually have a shell buffer nearby and go there to inspect the
> failed tests when I get no output. The problem is that shell blocks do
> not capture stderr. John Kitchin wrote a blog post
> <http://kitchingroup.cheme.cmu.edu/blog/2015/01/04/Redirecting-stderr-in-org-mode-shell-blocks/>
> about this problem and provided a solution that may work for you, but
> I have not tried it yet.

Ah yes... from my own comments there:

#+begin_src sh :results raw drawer :prologue "exec 2>&1" :epilogue ":"
python -m pytest ./utils
#+end_src

Thanks for reminding me about my past self.

  -k.

Re: [Proposal] Source Blocks with Post-Extensions

[Martin Alsinet]

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

Well Ken, you improved my workflow right there, I am going to add the
:prologue trick to my shell properties header and get the test error output
in the results block.

Thank you right back!

On Fri, Jul 26, 2019 at 10:18 AM Ken Mankoff <mankoff@gmail.com> wrote:

>
> On 2019-07-26 at 08:58 -04, Martin Alsinet <martin@alsinet.com.ar>
> wrote...
> > I usually have a shell buffer nearby and go there to inspect the
> > failed tests when I get no output. The problem is that shell blocks do
> > not capture stderr. John Kitchin wrote a blog post
> > <
> http://kitchingroup.cheme.cmu.edu/blog/2015/01/04/Redirecting-stderr-in-org-mode-shell-blocks/
> >
> > about this problem and provided a solution that may work for you, but
> > I have not tried it yet.
>
> Ah yes... from my own comments there:
>
> #+begin_src sh :results raw drawer :prologue "exec 2>&1" :epilogue ":"
> python -m pytest ./utils
> #+end_src
>
> Thanks for reminding me about my past self.
>
>   -k.
>

[-- Attachment #2: Type: text/html, Size: 1623 bytes --]