Skip to content

Add a supported hook for overriding the registry URL without writing config.yml #4878

Description

@drernie

Problem

quilt3.session.get_registry_url() reads the registry URL from ~/.quilt/config.yml on every call (via get_from_config('registryUrl') in util.py). For embedding scenarios where a host application needs to drive multiple catalogs in one process (or simply override the URL without persisting it), the only options today are:

  1. Call quilt3.config(url, ...) — which writes the user's config.yml on disk. Destructive for an embedder.
  2. Monkey-patch quilt3.session.get_registry_url — which is what we ended up doing in quiltx, and it's a smell: process-global mutation of an imported module's internals, no clean lifetime, embedder-hostile.

Proposal

Add a supported, in-process override for the registry URL. A few possible shapes, in order of preference:

(a) A resolver hook

quilt3.session.set_registry_url_resolver(callable_or_None)

When set, get_registry_url() calls the resolver instead of reading config. None restores default behavior. Pairs naturally with a contextmanager helper.

(b) An explicit override + contextmanager

with quilt3.session.use_registry_url("https://catalog.example.com"):
    quilt3.admin.users.list()

(c) A registry_url= kwarg on the public entrypoints quiltx uses (admin modules, search, GraphQL client, login). More invasive but most explicit.

Any of these would let quiltx delete its monkey-patch + ContextVar machinery (~40 lines of quilt3_facade.py) and stop reaching into quilt3.session internals.

Why this matters

  • quiltx advertises a Catalog.from_dns(...) embedding API. Without a supported hook, embedders inherit a process-wide quilt3.session.get_registry_url override that outlives their Catalog instance.
  • Internal-fan-out check: get_registry_url() is currently called from session.py auth flows, search_util.py, and _graphql_client/base_client.py (which captures the URL at client construction). All synchronous within a single call stack — no async/thread fan-out — so any of (a)/(b)/(c) is safe to implement.

Happy to send a PR for whichever shape is preferred.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions