Skip to content

Fix #245: I’ll inspect the issue details first, then trace the logging/config path handling locally#255

Merged
amjith merged 3 commits into
mainfrom
symphony/dbcli-litecli-245-attempt-10
May 26, 2026
Merged

Fix #245: I’ll inspect the issue details first, then trace the logging/config path handling locally#255
amjith merged 3 commits into
mainfrom
symphony/dbcli-litecli-245-attempt-10

Conversation

@dbcli-symphony
Copy link
Copy Markdown

Summary

  • I’ll inspect the issue details first, then trace the logging/config path handling locally before making the smallest code and test change. I’m using the GitHub skill for the issue context and the repo workflow.The local search points straight at litecli/main.py: audit logs already expand ~, but main.log_file is checked and opened without normalizing user paths. I’m going to pull the issue text/comments now to make sure the fix matches the reported behavior.Issue Getting error 'Unable to open log file' when log file move to other directory other than default #245 confirms the failure is with log_file = ~/.cache/litecli/log or -l ~/.cache/litecli/log; there are no discussion comments. Next I’m checking the existing tests around config/logging so the regression test lands in the right layer.The failing check is dir_path_exists(log_file) on the literal ~/.cache/... string. I’m going to normalize the configured log path before directory creation and handler setup, then add a narrow test that exercises initialize_logging() with HOME redirected to a temporary directory.The implementation is now one-line in the logging setup plus a regression test and changelog entry. I’m running the focused test first, then I’ll run a formatter/lint check if the test passes.The focused pytest invocation failed before collecting tests because the editable package metadata is not installed in this environment (PackageNotFoundError: litecli). I’m checking the package config and will install the local project editable if that’s sufficient without pulling new dependencies.This shell is picking up a parent .venv that has Python but no pip, so the usual editable install path is blocked. I’m checking for the repo’s available runners (uv, tox, direct module path workarounds) before choosing the least invasive verification route.The repo’s tox also installs via uv, so I’m going to add only the local editable package metadata with uv pip install --no-deps -e .; that avoids dependency resolution and should unblock direct pytest in the existing environment.uv tried to use the user-level cache outside the writable sandbox. I’m retrying with UV_CACHE_DIR under /private/tmp, still using --no-deps so it only installs this checkout’s metadata.uv is unusable in this sandbox because it panics while initializing. I’m checking alternate Python executables now; if one has pip and the test dependencies, I can run the focused test without touching the broken parent virtualenv.The usable environment has pytest and project dependencies but lacks only litecli package metadata. I’m going to run the narrow pytest in-process with a temporary importlib.metadata.version("litecli") shim so collection can proceed; this does not change repo files.The parent environment also lacks sqlparse, so normal pytest collection can’t run there. I’m checking whether the Homebrew-installed litecli environment already has the runtime dependencies available; if so, I can point Python at those packages and still run the local test code.Normal pytest is blocked by missing dependencies in the available virtualenvs. I’m trying a disposable venv under /private/tmp; if dependency installation can’t reach packages in this sandbox, I’ll fall back to syntax checks plus a small direct logging-path exercise.Dependency installation is blocked by network restrictions, so I can’t run the normal pytest target locally. I’m switching to local checks that don’t need external packages: compile, ruff on touched Python files, and a direct stubbed execution of the modified logging method.The direct logging exercise passes, and the touched Python files compile and pass ruff. I’m doing the final review pass now: whitespace/diff check plus a quick read for unintended behavior changes.Implemented the focused fix for issue Getting error 'Unable to open log file' when log file move to other directory other than default #245: initialize_logging() now expands ~ before creating/checking/opening the configured log path in litecli/main.py.
  • Added a regression test for ~/.cache/litecli/log in tests/test_main.py, and updated the Unreleased changelog in CHANGELOG.md.

Issue

Fixes #245

Verification

  • python -m py_compile litecli/main.py tests/test_main.py
  • ruff check litecli/main.py tests/test_main.py
  • ruff format --check litecli/main.py tests/test_main.py
  • git diff --check
  • Direct stubbed regression exercise for initialize_logging() with ~/.cache/litecli/log
  • Blocker: normal pytest could not run in this sandbox because the active env lacks litecli package metadata and runtime deps like sqlparse; dependency install was blocked by network restrictions.

@dbcli-symphony dbcli-symphony Bot force-pushed the symphony/dbcli-litecli-245-attempt-10 branch from 5c514eb to 28cde0e Compare May 26, 2026 04:22
@amjith amjith marked this pull request as ready for review May 26, 2026 14:49
@amjith amjith merged commit 6a3e595 into main May 26, 2026
10 of 11 checks passed
@amjith amjith deleted the symphony/dbcli-litecli-245-attempt-10 branch May 26, 2026 14:50
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.

Getting error 'Unable to open log file' when log file move to other directory other than default

1 participant