PR2: Define logging strategy and configuration #6

New issue

Closed

opened 2026-06-01 01:16:15 +00:00 by Grok · 2 comments

Grok commented

2026-06-01 01:16:15 +00:00

Member

For PR2 we need to introduce structured logging.

Open questions:

Use Python's logging module + basicConfig, or a more structured approach (e.g. structlog or loguru)?
Where should log files live? (user config dir, ~/.local/state, or per-project?)
Default log level in development vs packaged build?
Should we log to console + file by default?

Please provide guidance so we can implement cleanly in PR2.

For PR2 we need to introduce structured logging. Open questions: - Use Python's logging module + basicConfig, or a more structured approach (e.g. structlog or loguru)? - Where should log files live? (user config dir, ~/.local/state, or per-project?) - Default log level in development vs packaged build? - Should we log to console + file by default? Please provide guidance so we can implement cleanly in PR2.

Grok referenced this issue from a commit

2026-06-01 01:16:32 +00:00

feat: Add initial logging_config module (PR2 start)

ValleyGeek commented

2026-06-01 01:33:08 +00:00

Owner

Use built in logging, it shouldn't be a feature included in the final application so we'll use simple, but detailed, logs during development that can be excluded from the build releases. I would use an unimportant, or temp, path that's accessible but not critical or persistent. During development we should have very detailed logging to note which function failed in which file, how it was called and what its return state or error code was. There's no reason for the application to fail or crash without a useful log to pinpoint where, how, or the call attempted.

Grok referenced this issue from a commit

2026-06-01 02:01:56 +00:00

feat: Enhance logging for detailed development use (per issue #6)

Grok commented

2026-06-01 04:41:59 +00:00

Author

Member

Reviewed and incorporated feedback:

Switched to built-in logging module (no external libraries for production).
Added detailed formatter including filename, line number, and function name.
Default logs now go to a non-critical temp path (easy to exclude from releases).
Development logging is verbose as requested.

This aligns with PR2 direction. Closing as resolved.

Reviewed and incorporated feedback: - Switched to built-in logging module (no external libraries for production). - Added detailed formatter including filename, line number, and function name. - Default logs now go to a non-critical temp path (easy to exclude from releases). - Development logging is verbose as requested. This aligns with PR2 direction. Closing as resolved.

Grok closed this issue

2026-06-01 04:42:01 +00:00

Grok referenced this issue from a commit

2026-06-01 05:01:57 +00:00

fix(lint): break long dev formatter string to resolve E501 on python:3.12-bookworm runner

Grok referenced this issue from a commit

2026-06-01 05:22:13 +00:00

docs: advance milestone status from PR2 to PR3

Grok referenced this issue

2026-06-04 18:08:10 +00:00

PR7: Metadata enrichment scan respects UI sort order (DR-014) #17