Prompting user input

[khharut]

reticulate/R/config.R

Line 476 in d683b3b

permission <- utils::askYesNo(sprintf(

Please remove this logic. In case of non-interactive session initialization of python for most cases would fail, even if there are Python installed on the OS.

[t-kalinowski]

That code is only executed in interactive sessions. See just one line above

reticulate/R/config.R

Lines 475 to 476 in d683b3b

	if (is_interactive()) {
	permission <- utils::askYesNo(sprintf(

What is the problem or error you are encountering?
Please avoid spamming multiple issue.

[khharut]

Hi, thanks for quick response. The problem is that I have OS python and I do not want any virtual python environment at all. And each time when I restart R session and executing: reticulate::py_available(initialize = TRUE), I have to answer question "Would you like to create a default Python environment for the %s package?", since each time I am saying "No". Don't you think it is annoying? I have found a solution:

Sys.setenv(RETICULATE_AUTOCREATE_PACKAGE_VENV = 0)
reticulate::py_available(initialize = TRUE).

But I do not like it either, since I have to deal with some unknown environment variable.

Therefore I am asking please change the logic. It is very strange behavior and I spent whole day understanding it.

[khharut]

And about other issue, I think it is not related to this directly. Any environment variable must be well-documented and has solid use case. Otherwise, one can invent as much as he wants and that will over-complicate the code. And because of that, I am asking please please remove that environment variable. Thanks again.

[t-kalinowski]

If you have a strong preference for which Python you want reticulate to use, I suggest setting the environment variable RETICULATE_PYTHON to the path to the Python executable. e.g., in .bashrc or .bash_profile or .Renviron,

export RETICULATE_PYTHON=/usr/bin/python

Or in .Rprofile

Sys.setenv("RETICULATE_PYTHON" = "/usr/bin/python")

I agree that reticulate should remember if the user declined to create the venv and not ask again.

That said, the default is the default because it leads to the most consistently positive experience for users. Defaulting to the system python leads to problems when you begin installing packages - it often results to a very broken installation with no easy way to revert to a working state, especially for novices to Python installation management.

I encourage you to accept the prompt and let reticulate default to using the r-reticualte venv.

You may also want to look at the "Order of Discovery" to understand how reticualte selects a Python installation to bind to. https://rstudio.github.io/reticulate/articles/versions.html#order-of-discovery

[khharut]

Hi,

let me do not accept with such a workaround. You again try to convince me that environment variable is a good approach. And one has to define environment variable $A or $B to make a module work as it is intended to work. Again, I think makes very hard to follow the idea for new user. Why just do not add a new parameter to a function? It is more easy to implement and easy to document. And environment variable definition depends on OS and sometimes one has to restart server to make them work. And defining environment variables for Windows OS is really nightmare.

My idea is simple. Just add a new parameter to skip creating mandatory python virtual environment and remove some useless environment variables. Usage of environment variable must be exceptional, only for the cases when other approaches do not work at all.

Thank you for your time and readiness to help.

Regards,
Harutyun

[nevrome]

Hi @t-kalinowski - thank you for sharing this great package! I think @khharut has a point here, though.

I'm using reticulate to build a little wrapper R package for a python library. The python library is difficult to install and requires a specific conda environment. Of course I will document the installation procedure for the python library well, but let's assume some user gets it wrong and runs any of my packages' python-calling functions without a well prepared python environment. Of course they would then get the good old

Would you like to create a default Python environment for the reticulate package? (Yes/no/cancel)

At first glance this sounds good. So they may say "Yes", wait a couple of seconds to let reticulate do it's wizardry, and then of course fail yet again, because the new, bare python environment does not include the necessary dependencies. I don't think this is helpful. But maybe I misunderstand how this works?

Usually I would just avoid this particular behaviour of your package. But because of the way it is integrated in reticulate, it is hard to circumvent. Look for example at this call to assert of the checkmate package, which I often use to validate user input and environment settings:

check_python_module_available <- function(x) {
  # this check loads the environment
  if (reticulate::py_module_available(x)) {TRUE}
  else { paste(x, "module not available for", reticulate::py_exe()) }
}
checkmate::assert(check_python_module_available("xxx"))

I can't check if the python dependency is there, without triggering the Would you like to... prompt. And that is suboptimal for my particular usecase.

I'm happy to take any suggestions how to solve this in the way you intended. But maybe it would indeed be best to remove this wizard.

[t-kalinowski]

@nevrome thanks for posting.

Have you seen https://rstudio.github.io/reticulate/articles/python_dependencies.html? There we outline an approach for how to approach this in an R package.

We currently recommending calling use_virtualenv("r-pkgname", required = FALSE) in .onLoad(), and providing a install_pypkgs() helper, to create the r-pkgname venv.

Note, we're actively working on this problem and in the next reticulate release we will simplify this approach even further.

[nevrome]

Thanks for the quick answer! I have indeed not seen this post, only the preceding Using reticulate in an R Package. I absolutely appreciate that you put so much thought into this, but I'm not sure if I agree with the proposed solutions. Maybe I'll come around eventually 🙂

Currently I think I would prefer a workflow that makes users very conciously create an environment manually on the command line, or with reticulate::conda_create, and set it in the respective script with reticulate::use_python for my usecase.

For me this sounds a bit like a question of taste. Could you consider making the prompt in question optional, so that alternative approaches are more viable?

[t-kalinowski]

The prompt will go away in the next release :)

[nevrome]

Great! Thanks 🙏 ! I'm looking forward to it then!