feat(config): custom config path

[lexasub]

Description

Add config path

@r0h1tb I'm not sure if we need this for debugging purposes in the main branch, what do you think?

[r0h1tb]

hey @lexasub — good question, here's my honest take:

the env var (AST_RAG_CONFIG) is worth keeping — right now if you run ast-rag from a directory that doesn't have

ast_rag_config.json
, it silently falls back to defaults with no indication. env var is the standard fix for this (KUBECONFIG, AWS_CONFIG_FILE etc all follow this pattern).

the script-dir fallback (Path(file).parent) i'm less sure about — if someone ships a default config inside the package and a user runs from /tmp/, they'd silently pick up the package-level config instead of their own. unusual precedence that could cause surprise. most tools go: flag → env var → CWD → defaults. i'd drop the script-dir step.

the logging — logger.info on every config load is noisy (fires on every MCP tool call since _get_api() is called per-request). logger.debug for successful loads, logger.warning for the "no config found" case would be cleaner.

bigger concern: the config logic is now duplicated in cli.py and ast_rag_mcp.py with slightly different implementations. services/config.py has a third path (ServiceConfig.from_json()) that doesn't get any of these fallbacks. a shared load_config(config_path=None) → ProjectConfig helper in config.py that everyone calls would be the right fix.

happy to take a crack at that refactor in a follow-up PR if you want to merge the env var piece first, or we can do it all in one shot here.

[lexasub]

good, do it all in your new pr пятница, 13 марта 2026 г. пользователь r0h1tb ***@***.***> написал:

…

***@***.**** commented on this pull request. hey @lexasub <https://github.com/lexasub> — good question, here's my honest take: the env var (AST_RAG_CONFIG) is worth keeping — right now if you run ast-rag from a directory that doesn't have ast_rag_config.json , it silently falls back to defaults with no indication. env var is the standard fix for this (KUBECONFIG, AWS_CONFIG_FILE etc all follow this pattern). the script-dir fallback (Path(*file*).parent) i'm less sure about — if someone ships a default config inside the package and a user runs from /tmp/, they'd silently pick up the package-level config instead of their own. unusual precedence that could cause surprise. most tools go: flag → env var → CWD → defaults. i'd drop the script-dir step. the logging — logger.info on every config load is noisy (fires on every MCP tool call since _get_api() is called per-request). logger.debug for successful loads, logger.warning for the "no config found" case would be cleaner. bigger concern: the config logic is now duplicated in cli.py and ast_rag_mcp.py with slightly different implementations. services/config.py has a third path (ServiceConfig.from_json()) that doesn't get any of these fallbacks. a shared load_config(config_path=None) → ProjectConfig helper in config.py that everyone calls would be the right fix. happy to take a crack at that refactor in a follow-up PR if you want to merge the env var piece first, or we can do it all in one shot here. — Reply to this email directly, view it on GitHub <#26 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD4EFN55TZOVQTESULSLXFD4QPJVLAVCNFSM6AAAAACWNSPF3CVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTSNBSG44DQOJYHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>