`mem0.proxy` runs `pip install litellm` at import time and calls `sys.exit(1)` on failure

[rajarshidattapy]

Component

Python SDK

Description

Summary

The top of mem0/proxy/main.py mutates the user's environment as a side effect of an import, and terminates the host process if that mutation fails:

# mem0/proxy/main.py, lines 11-18
try:
    import litellm
except ImportError:
    try:
        subprocess.check_call([sys.executable, "-m", "pip", "install", "litellm"])
        import litellm
    except subprocess.CalledProcessError:
        print("Failed to install 'litellm'. Please install it manually using 'pip install litellm'.")
        sys.exit(1)

Three distinct problems, one root cause (doing dependency management at import time):

1. Unsolicited installation. import mem0.proxy.main downloads and installs a package into whatever environment sys.executable points at. In a container, a locked/hash-pinned deployment, a --require-hashes environment, or a read-only site-packages, this is at best surprising and at worst a supply-chain and reproducibility problem — the resolver is free to pull any litellm version plus its transitive tree, with no version constraint from mem0.
2. sys.exit(1) inside a library. A library import must not terminate the host process. Any web server, notebook, or agent runtime that imports this module in a sandbox with no network dies with SystemExit instead of getting a catchable ImportError.
3. Wrong exception is caught. Only subprocess.CalledProcessError is handled. A FileNotFoundError (no pip module in the environment, e.g. a slim or --no-pip venv) or a PermissionError propagates raw out of the import statement.

Every other optional dependency in the codebase uses the normal pattern — raise ImportError with an install hint (see mem0/vector_stores/oracledb.py, _create_procedural_memory's langchain-core guard, etc.). litellm is already declared in the llms extra in pyproject.toml, so the correct install path exists and is simply not pointed at.

Steps to Reproduce

# In a fresh venv with mem0ai installed but WITHOUT litellm, and with the
# network blocked (or site-packages mounted read-only):
#
#   python -m venv venv && ./venv/bin/pip install mem0ai
#   ./venv/bin/python -c "import mem0.proxy.main"

from mem0.proxy.main import Mem0   # triggers the pip install before this line resolves

client = Mem0(config={...})

Expected Behavior

The import raises a normal, catchable error and tells the user what to install, without touching the environment:

ImportError: litellm is required for mem0.proxy. Install it with 'pip install "mem0ai[llms]"'.

Actual Behavior

With network access, pip install litellm runs unprompted and installs an unpinned litellm plus its dependency tree into the active environment.

Without network access, the subprocess fails and the interpreter is killed by the library:

Failed to install 'litellm'. Please install it manually using 'pip install litellm'.
SystemExit: 1

In an environment with no pip module the uncaught branch fires instead:

FileNotFoundError / ModuleNotFoundError: No module named pip

Environment

• mem0 version: 2.0.17 (main @ 12c47f5)
• Python/Node version: Python 3.11.9
• OS: Windows 11 (platform independent)