Skip to content

fix(palace): honour MEMPALACE_BACKEND env var so entry-point backends are actually used#1072

Open
malakhov-dmitrii wants to merge 1 commit intoMemPalace:developfrom
malakhov-dmitrii:fix/palace-honor-backend-env-var
Open

fix(palace): honour MEMPALACE_BACKEND env var so entry-point backends are actually used#1072
malakhov-dmitrii wants to merge 1 commit intoMemPalace:developfrom
malakhov-dmitrii:fix/palace-honor-backend-env-var

Conversation

@malakhov-dmitrii
Copy link
Copy Markdown

Summary

palace._DEFAULT_BACKEND is hard-coded to ChromaBackend(), so the MEMPALACE_BACKEND environment variable that backends.registry.resolve_backend_for_palace is documented to honour (RFC 001 §3.3 priority 3) has no effect on the miner, search, or the MCP server.

As a result, third-party backends declared via the mempalace.backends entry point are discoverable via available_backends() but never actually used in practice.

This PR wires palace._DEFAULT_BACKEND through the registry so an opt-in env var selects the backend, and falls back to ChromaBackend when no override is set — existing installs behave exactly as before.

Change

def _resolve_default_backend():
    name = resolve_backend_for_palace(
        env_value=os.environ.get("MEMPALACE_BACKEND"),
    )
    if name == "chroma":
        return ChromaBackend()
    return get_backend(name)


_DEFAULT_BACKEND = _resolve_default_backend()

+17 / -1 in one file.

Why this matters

With this single hook in place, a backend distributed as a separate package (e.g. the in-development mempalace-postgres) can be selected simply with:

pip install mempalace-postgres
export MEMPALACE_BACKEND=postgres
export MEMPALACE_PG_DSN=postgres://…
mempalace mine ./my-project

No fork, no monkey-patch, no touching the Chroma default.

This unlocks the contract already described in backends/registry.py and aligns the default-selection path with the RFC 001 priority order.

Scope

Deliberately minimal:

  • No behavioural change for existing Chroma users (when MEMPALACE_BACKEND is unset the resolution lands on "chroma" and we still instantiate ChromaBackend() directly).
  • No new dependencies.
  • No changes to the get_collection call site — only the resolution of _DEFAULT_BACKEND.

Test plan

  • Unset MEMPALACE_BACKENDmempalace mine still uses Chroma (no regression).
  • Export MEMPALACE_BACKEND=chroma → identical behaviour.
  • Export MEMPALACE_BACKEND=<bogus> → early KeyError: unknown backend from the registry (fail fast, same as existing get_backend behaviour).
  • With an entry-point backend installed (e.g. mempalace-postgres) and MEMPALACE_BACKEND=postgres → miner writes to that backend.

…backend

Previously `palace._DEFAULT_BACKEND` was hard-coded to `ChromaBackend()`,
silently ignoring the `MEMPALACE_BACKEND` environment variable that
`backends.registry.resolve_backend_for_palace` is documented to honour
(RFC 001 §3.3 priority 3). This meant entry-point backends such as
`mempalace-postgres` were discoverable via `available_backends()` but
never actually used by `mine`, `search`, or the MCP server.

Now `palace._DEFAULT_BACKEND` is produced by `_resolve_default_backend()`,
which consults `MEMPALACE_BACKEND` through the registry and falls back to
`ChromaBackend` when no override is set. Existing callers are unchanged;
installations without the env var behave exactly as before.

This is the smallest change that makes the pluggable backend contract
described in `backends/registry.py` usable in practice.
@igorls igorls added bug Something isn't working storage labels Apr 24, 2026
jphein added a commit to jphein/mempalace that referenced this pull request Apr 24, 2026
…alace#1072 exist, not a write-from-scratch

Previous version claimed Postgres was "out of scope — requires writing a
new BaseBackend implementation". That was wrong: @skuznetsov's MemPalace#665 already
ships a PostgreSQL backend (pg_sorted_heap preferred, pgvector fallback),
and @malakhov-dmitrii's MemPalace#1072 wires MEMPALACE_BACKEND env var through
palace._DEFAULT_BACKEND so entry-point backends actually get used. RFC 001
seam (MemPalace#413, MemPalace#995) is merged; registry.py advertises mempalace_postgres as
the canonical example.

Reframed as parallel track: palace-daemon is deployable today (no
migration, wraps current ChromaDB palace); Postgres needs both PRs to land
plus a drawer migration (export_palace() + importer — not code we'd write)
but eliminates the entire 1.5.x failure class at the storage layer.
Starting with palace-daemon since it's deployable now; the daemon is
storage-agnostic so Postgres remains available as a later swap.

Also fixed palace-daemon lock path: /tmp/palace-daemon-8085.lock (per-port),
not /tmp/palace-daemon.lock.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working storage

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants