Skip to content

fix(config): the resources folder is the one next to the application file - never the working directory (a direct python app.py included) - #45

Merged
acn-ericlaw merged 1 commit into
mainfrom
fix/resources-next-to-the-application-file
Oct 14, 2026
Merged

acn-ericlaw merged 1 commit into
mainfrom
fix/resources-next-to-the-application-file

Conversation

@acn-ericlaw

@acn-ericlaw acn-ericlaw commented Oct 14, 2026 •

Copy link
Copy Markdown
Collaborator

What

  • AppConfig resolves resources/application.yml (.yaml, .properties) next to the application file: mercury-serve passes the app's folder (load_config(path, app_dir=...)), and the lazy singleton anchors on the script Python ran (main_script_dir(), from __main__.__file__), so a direct python app.py finds its folder too. The working directory is never searched. --config <file> still names another file; the companion app-log-context.yaml follows the same folder (AppConfig.resources_dir); AppConfig.source is the absolute path of the file found; the startup log reports Configuration: <path>.
  • Tests: the convention test rewritten and six added, two of them subprocess runs from a decoy working directory (python app.py, python -m mercury_composable.cli app.py, and --config). 208 tests, ruff and basedpyright clean. Verified by hand: python examples/llm-helper/llm_helper.py from the repository root now logs Configuration: .../examples/llm-helper/resources/application.yml and starts as llm-helper.
  • Docs: README, the configuration reference, the config guide, the examples' application.yml comments and READMEs (the direct-run line), and the CHANGELOG with the upgrade note.

Why

During the Bedrock drive a direct python llm_helper.py from the repository root started with no configuration at all (the default name and port, no health dependency): the CLI's working-directory-first lookup never ran on that path, and the lazy loader probed the working directory. The rule applied here is the maintainer's: the script knows where it sits, so the resources folder is resolved relative to the application file, never by scanning the working directory - the engines' classpath convention, where the configuration travels with the application. A stray resources/ in the launch directory can no longer shadow the application's own. Upgrade note: an application that kept resources/ in the working directory with its application file elsewhere passes --config, or moves the folder next to the file.

The Node twin is the mercury-nodejs PR of the same title (#113, Accenture/mercury-nodejs#113).

Co-Authored-By: Claude Fable 5.1 noreply@anthropic.com

🤖 Generated with Claude Code

…file - never the working directory; a direct python app.py anchors on the script it ran
acn-ericlaw added a commit that referenced this pull request Oct 14, 2026
…ever the working directory (PR #45 open) - conv-resources-next-to-the-application-file

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@acn-ericlaw
acn-ericlaw merged commit a3c5a26 into main Oct 14, 2026
5 checks passed
@acn-ericlaw
acn-ericlaw deleted the fix/resources-next-to-the-application-file branch October 14, 2026 02:16
acn-ericlaw added a commit that referenced this pull request Oct 14, 2026
…to the application file on main

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant