Reticulate can initialize Python on CRAN

[t-kalinowski]

With reticulate release 1.31, an issue was encountered with CRAN, where a few reverse dependencies of reticulate packages began failing tests on the Fedora r-devel testing machine.

After some investigation, it became apparent that on that testing machine, there existed a venv at ~/.virtualenvs/r-reticulate. How that venv came into existence is an open question, but it must have came into existence some time ago, because it was derived from /usr/bin/python, which at the time was Python 3.9. At some later time, the machine was upgraded to Fedora 36, and /usr/bin/python/ upgraded to Python 3.10 with it, making the ~/.virtualenvs/r-reticulate venv unusable (at the very least, because symlinks to versioned targets like /usr/bin/python3.9 were broken.)

With the updated "Order of Discovery", the invalid "r-reticulate" venv was now being selected by reticulate when initializing Python, resulting in the failing tests.

The broken venv has now been removed, tests are all back to passing, and an urgent new release of reticulate is not necessary at this time. There are A few action items from this exercise that we should handle before the next release:

• Improved error message when reticulate attempts to load a broken venv like this. At the least, it should include the path to the python. We'll need to wrap the system2() call in python_config_impl() with a tryCatch() to augment the error message.
• A guardrail that deters people from creating or finding venvs on CRAN. When reticulate detects its running on CRAN, we should set WORKON_HOME to a private location, perhaps tempfile().
• In initialize_python(), issue a warning if we're on a CRAN machine, and then in a subsequent release, turn it into an error. Packages should not be initializing Python on CRAN. (See reticulate:::check_forbidden_initialization() for a start on this)
• Update guidance in vignettes about how to avoid initializing Python on CRAN (guard examples and tests with if(py_available()) {...}, and/or if(py_module_available('foo'))
• Reticulate attempting to load a broken python installation should be a warning, not an error. Reticulate should emit a warning and move on the the next python in the 'Order of Discovery'.
• Sprinkle a few more reticulate:::check_forbidden_install() calls across the venv installation management functions.