fix(console): don't warn on missing path dep in excluded group

[St4r4x]

Resolves: #10461

Problem

PathDependency.__init__ (in poetry-core) unconditionally logs a warning if a path/directory/file dependency's target doesn't exist, at the point the full pyproject.toml is parsed — before this CLI has determined which --with/--without/--only groups are actually active for the current install/sync invocation. So a path dependency in an excluded group (e.g. a dev-only local package that's never copied into a Docker image) gets flagged even though it was never going to be installed.

The already-correct, group-aware validation in Installer (installer.py:373, dep.validate(raise_error=not op.skipped)) still runs afterward and is unaffected — a path dependency that IS actually needed and IS missing still fails install/sync with a real error, exactly as before.

Fix

Added a suppressed_loggers mechanism to Command (parallel to the existing loggers list register_command_loggers already reads), letting a command raise specific loggers above WARNING for itself, unless run with --verbose/-vv/--debug. InstallCommand (and SyncCommand, which inherits from it) uses this to suppress poetry.core.packages.path_dependency's premature warning.

While testing, found and fixed a related issue: logger levels are global process state, so an earlier version of this raised the level but never reset it for a later command in the same process that doesn't ask for suppression. Application now tracks which logger names it's currently suppressing and resets any a new command doesn't ask for — relevant for anything running more than one command per process, this repo's own test suite included.

Nothing changed in poetry-core; this is scoped entirely to how this CLI configures logging per command.

Tests

• tests/console/test_application.py: new test covering default/--verbose/-vv.

• tests/console/commands/test_install.py: existing fixtures already cover the scenario. Ran the full suite deterministically and with randomized order (several times) specifically to rule out logger-state leakage across tests.

• Added tests for changed code.

• Documentation: none needed, internal logging fix with no user-facing API change.

---

Note on process: I worked on this with AI assistance (Claude) to investigate the root cause, write the fix, and write/run the tests. I reviewed and understand the changes and I'm the one deciding what's in this PR.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• When resetting previously suppressed loggers in register_command_loggers, you currently set them to the global level, which can overwrite any prior per-logger configuration; consider capturing and restoring each logger’s original level (e.g., via a small mapping keyed by logger name) so that suppression is strictly temporary and does not alter existing logging configuration beyond the lifetime of the command.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- When resetting previously suppressed loggers in `register_command_loggers`, you currently set them to the global `level`, which can overwrite any prior per-logger configuration; consider capturing and restoring each logger’s original level (e.g., via a small mapping keyed by logger name) so that suppression is strictly temporary and does not alter existing logging configuration beyond the lifetime of the command.

## Individual Comments

### Comment 1
<location path="src/poetry/console/application.py" line_range="593-594" />
<code_context>
+        # Mutated in place (rather than `self._suppressed_logger_names = ...`)
+        # so the update lands on the shared ClassVar instead of shadowing it
+        # with a same-named instance attribute.
+        for name in Application._suppressed_logger_names - to_suppress:
+            logging.getLogger(name).setLevel(level)
+
+        for name in to_suppress:
</code_context>
<issue_to_address>
**issue (bug_risk):** Restoring suppressed loggers to `level` may unintentionally lower externally configured log levels.

This loop sets each previously suppressed logger to the command’s `level`, which can lower a logger that was externally configured to a stricter level (e.g., CRITICAL) down to WARNING/INFO on later, less-verbose commands. To avoid overriding stricter policies, consider either tracking which loggers were temporarily bumped to ERROR and only resetting those, or resetting with something like `max(existing_level, level)` instead of always applying `level`.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

Sourcery assessment

Approved.

[sourcery-ai]

Sourcery assessment

Approved.

[St4r4x]

Quick note: the previous push briefly broke CI (macOS/Python 3.13, --integration) - test_application_suppressed_logger_is_restored_to_its_prior_level failed with assert 50 == 40. Root cause was test-order dependence, not a real issue in the fix itself: the other test in this PR suppresses the logger but never runs a follow-up command that isn't in suppressed_loggers, so it never exercises the restore path and leaves the logger's entry sitting in Application._suppressed_logger_levels for whatever test happens to run next in the same worker.

Fixed by making with_add_warn_command_plugin reset both the logger and that entry before and after each test, rather than relying on each test to clean up after itself. Verified with 7 different pytest-randomly seeds and a full tests/console/ run before pushing again - CI is green now.