Can you test against your macOS Python installation or another install of Python to see if this is specific to Anaconda?
Can you also test and see if you can source a .py file in your RStudio session? This would indicate whether the issue lies with the .Rmd file or with something in RStudio more generally.
However, when I comment out the use_condaenv line it works (both with the built-in python2.7 and python3 if I specify which python to use). So perhaps it is a conda thing.
Using /usr/bin/python3:
I made a file called add.py and tried to source it and got the following:
Error in py_run_string_impl(code, local, convert) :
NameError: name 'source_python' is not defined
Edited: I ran source_python() in the python chunk above, not realizing it was a function in the reticulate r package. When I ran it in the r chunk it worked just fine.
@delphis
I am using reticulate in production, And I suggest you directly config the reticulate_python in your .Renviron, which will save you a lot of time
I made a brand new conda environment and py_config() worked as did import os. So perhaps there is indeed something wrong with my previous 'phylo3' environment as kevinushey says - although I can import os perfectly well in a python interpreter.
If you wanted to get to the bottom of it, you could try attaching a debugger (e.g. gdb) to the R process, and trying to get a backtrace to see what's crashing when os is loaded. For example:
First, close any running instances of RStudio, and then launch a new lone RStudio instance.
Then, in a terminal, start GDB and have it attach to RStudio. You should be able to do this with:
sudo gdb -p `pidof rsession`
If you do not have the pidof utility installed, you can run Sys.getpid() in your R session to get the session's process ID.
After this, GDB should (hopefully) successfully attach to the process. Next, we'll instruct GDB to log to a file:
set logging file rstudio.log
set logging on
Finally, we'll tell GDB to let RStudio continue running:
continue
Now, return to your RStudio session and try running the code that triggered the crash. With luck, if RStudio crashes, GDB should catch the fault. Return to GDB, and enter:
backtrace
You should now be able to quit GDB with
quit
and then make the file at 'rstudio.log' available to us for further inspection.