The `castle` CLI and the `castle-api` service are two independent in-process drivers of `castle_core`. Each resolved DATA_DIR/REPOS_DIR at import time from its own process env (default /data/castle), persisted nowhere — so they silently diverged, and `apply`/dashboard-apply crashed on a non-existent /data. Make the loaded CastleConfig the single source of truth: - Resolve data_dir/repos_dir only in load_config (env > castle.yaml > default), anchored to the config root; drop the DATA_DIR/REPOS_DIR module globals and the import-time file read entirely — no global twin that can disagree with the file. - Thread config.data_dir/repos_dir through ensure_dirs, _env_context, tls_dir_for (now unified — deploy no longer inlines the tls path), and create/add/clone. - ensure_dirs raises an actionable CastleDirError instead of a bare PermissionError; the api surfaces it as 422. - doctor: "data dir writable" check + WARN when CASTLE_DATA_DIR/REPOS_DIR env overrides the file (the one remaining cross-process divergence vector). - install.sh persists data_dir/repos_dir into castle.yaml (idempotent, non-default). - Docs: registry.md globals + AGENTS.md roots. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
29 lines
630 B
Python
29 lines
630 B
Python
"""Re-export from castle-core for backward compatibility."""
|
|
|
|
from castle_core.config import * # noqa: F401, F403
|
|
from castle_core.config import ( # noqa: F401 — explicit re-exports for type checkers
|
|
ARTIFACTS_DIR,
|
|
CASTLE_HOME,
|
|
CODE_DIR,
|
|
CONTENT_DIR,
|
|
GENERATED_DIR,
|
|
SECRETS_DIR,
|
|
SPECS_DIR,
|
|
STATIC_DIR,
|
|
CastleConfig,
|
|
GatewayConfig,
|
|
ensure_dirs,
|
|
find_castle_root,
|
|
load_config,
|
|
resolve_env_vars,
|
|
save_config,
|
|
)
|
|
from castle_core.registry import ( # noqa: F401
|
|
REGISTRY_PATH,
|
|
Deployment,
|
|
NodeConfig,
|
|
NodeRegistry,
|
|
load_registry,
|
|
save_registry,
|
|
)
|