How to use R interpreter installed in a conda environment?

[ami-null]

From my testing, Positron does not detected R interpreters installed in conda environments. Is it not supported? If not supported, is it planned?

[juliasilge]

Thanks for this question! We don't currently do automatic discovery of R interpreters installed via conda and I have opened #4398 to track and prioritize this work.

As a workaround for now, can you try launching Positron from a conda env and see if that works for you? I believe the steps would be:

• Put Positron on the path, like this
• Activate your conda env
• Launch Positron from the shell where your conda env is activated, like via positron .

[ami-null]

I am using miniforge on Linux Mint 22 (Ubuntu 24.04).
The R interpreter starts, and seem to work fine. But, I get the following warning:

Warning message:
In startDynamicHelp(TRUE) :
  unable to load shared object '/home/ami-null/miniforge3/envs/jpr/lib/R/modules//internet.so':
  /lib/x86_64-linux-gnu/libssl.so.3: version `OPENSSL_3.2.0' not found (required by /home/ami-null/miniforge3/envs/jpr/lib/R/modules//../../libcurl.so.4)

Output of sessionInfo() from R inside Positron:

> sessionInfo()
R version 4.3.3 (2024-02-29)
Platform: x86_64-conda-linux-gnu (64-bit)
Running under: Linux Mint 22

Matrix products: default
BLAS/LAPACK: /home/ami-null/miniforge3/envs/jpr/lib/libopenblasp-r0.3.27.so;  LAPACK version 3.12.0

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_US.UTF-8       
 [4] LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                  LC_ADDRESS=C              
[10] LC_TELEPHONE=C             LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

time zone: [REMOVED]
tzcode source: system (glibc)

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
[1] compiler_4.3.3 tools_4.3.3   

Installed Conda (conda-forge) packages related to openssl:

$ mamba list | grep openssl
openssl                   3.3.1                h4bc722e_2    conda-forge
r-openssl                 2.2.1             r43h5bbf899_0    conda-forge

Ubuntu openssl package:

$ apt list openssl
Listing... Done
openssl/noble-updates,noble-security,now 3.0.13-0ubuntu3.2 amd64 [installed]

[juliasilge]

This looks to me like a problem with your conda env, probably the interaction between versions of curl and openssl (looks like it is trying to use curl from outside the env?). The call to startDynamicHelp(TRUE) comes from inside R itself. You can try to confirm if it is/is not a Positron problem by activating your conda env and then starting R from the terminal. If you run tools::startDynamicHelp(TRUE) from R outside of Positron (just starting R from the command line), you can see if you see the same error.

[MustafaElshani]

I have the exact same issue only appear while running positron. There are no issues with R when running from terminal within the mamba env. I have tried also using VScode and no issue there either. The issue only appears when running Positron

[MustafaElshani]

I manged to get it to work by

mamba deactivate 
positron

Still uses all the miniforge environment correctly but no issue with library
I suspect its something to do with LD_LIBRARY_PATH

This also works

export LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libssl.so:/usr/lib/x86_64-linux-gnu/libcurl.so"
positron

[juliasilge]

This may be resolved after posit-dev/ark#487 is pulled into a public-facing release build, as it removes the dependency on openssl.