2025, Oct 28 13:00

Resolve rgee Earth Engine setup: fix ee_Initialize credential errors by pinning earthengine-api 0.1.370 on Python 3.11

Troubleshoot rgee setup: fix ee_Initialize credential errors by aligning reticulate, Python 3.11, and earthengine-api 0.1.370 for stable Earth Engine workflow

Getting rgee up and running can look straightforward until you hit opaque errors mid-setup. A typical friction point is a silent mismatch between rgee, the Earth Engine Python client (earthengine-api), and the Python version available via reticulate. Below is a concise walkthrough of the exact failure pattern and the steps that resolved it.

Reproducing the issue

The setup starts normally: install rgee, check Python through reticulate, point rgee to a system Python, then validate the environment. Despite that, the check fails and later initialization throws a credential error that persists after re-authentication.

install.packages("rgee")
library(rgee)
reticulate::py_available()
reticulate::py_discover_config()
# point rgee to the system Python and name the py env
rgee::ee_install_set_pyenv(py_path = "/usr/bin/python", py_env = "gee_env")
# environment check
rgee::ee_check()
# optional checks
rgee:::ee_check_python_packages()
rgee:::ee_check_credentials()
# initialize Earth Engine
acct_email <- "maanan.said@gmail.com"
rgee::ee_Initialize(user = acct_email)

The first symptom appears during the environment check with an error like “Error in strsplit(a, "[.-]"): non-character argument”. Proceeding further shows earthengine-api present but at 1.5.24 while rgee indicates it was tested with 0.1.370. Credentials are found, yet ee_Initialize ends with “It looks like your EE credential has expired…”, and re-authentication does not change the outcome.

What’s really going on

The root cause is a version incompatibility between rgee, the installed earthengine-api, and Python 3.13. The mismatch surfaces first as the ee_check error and later as a seemingly unrelated initialization failure that persists even after cleaning and re-authenticating. Aligning the versions resolves both.

Fix that works

The resolution is to use Python 3.11, isolate a fresh environment for rgee, pin earthengine-api to 0.1.370, then clean and re-authenticate.

# install Python 3.11 and create a dedicated env for rgee
rgee::ee_install_python(py_env = "gee_env", py_version = "3.11")
# explicitly bind rgee to the Python 3.11 interpreter and the new env
rgee::ee_install_set_pyenv(py_path = "/usr/bin/python3.11", py_env = "gee_env")
# match the earthengine-api version rgee was tested with
reticulate::py_install('earthengine-api==0.1.370', envname = "gee_env")
# reset and initialize credentials
acct_email <- "maanan.said@gmail.com"
rgee::ee_clean_user_credentials(user = acct_email)
rgee::ee_Initialize(user = acct_email, drive = TRUE, gcs = TRUE)

Why this matters

rgee bridges R and the Earth Engine Python API through reticulate. When the Python interpreter, the earthengine-api package, and rgee are out of sync, you can see validation errors during ee_check and downstream failures in ee_Initialize that masquerade as credential problems. Keeping these pieces aligned avoids hours of trial-and-error and prevents brittle setups.

Practical takeaways

When configuring rgee, isolate it in a dedicated Python environment based on Python 3.11, pin earthengine-api to 0.1.370 as indicated by rgee’s check, then reinitialize credentials. This sequence eliminates the reported check error and the persistent initialization failure, yielding a stable Earth Engine workflow from R.

The article is based on a question from StackOverflow by Saïd Maanan and an answer by Saïd Maanan.