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
Open
Conversation
…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.
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
palace._DEFAULT_BACKENDis hard-coded toChromaBackend(), so theMEMPALACE_BACKENDenvironment variable thatbackends.registry.resolve_backend_for_palaceis 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.backendsentry point are discoverable viaavailable_backends()but never actually used in practice.This PR wires
palace._DEFAULT_BACKENDthrough the registry so an opt-in env var selects the backend, and falls back toChromaBackendwhen no override is set — existing installs behave exactly as before.Change
+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:No fork, no monkey-patch, no touching the Chroma default.
This unlocks the contract already described in
backends/registry.pyand aligns the default-selection path with the RFC 001 priority order.Scope
Deliberately minimal:
MEMPALACE_BACKENDis unset the resolution lands on"chroma"and we still instantiateChromaBackend()directly).get_collectioncall site — only the resolution of_DEFAULT_BACKEND.Test plan
MEMPALACE_BACKEND→mempalace minestill uses Chroma (no regression).MEMPALACE_BACKEND=chroma→ identical behaviour.MEMPALACE_BACKEND=<bogus>→ earlyKeyError: unknown backendfrom the registry (fail fast, same as existingget_backendbehaviour).mempalace-postgres) andMEMPALACE_BACKEND=postgres→ miner writes to that backend.