feat: classify conditional imports

[TristanKruse]

Pull Request

Adds first-class classification for conditional imports inside try blocks that handle ImportError or ModuleNotFoundError.

These imports are now marked with ImportKind.CONDITIONAL_IMPORT, allowing dependency graphs and reports to distinguish optional/fallback dependencies from regular runtime imports.

This PR includes regression tests for conditional imports in raw import extraction and graph extraction, plus a short README note documenting the behavior.

Change Type

• Bug fix
• Feature
• Documentation
• Refactoring

[TristanKruse]

Validation:

• pytest tests\common\test_extract_graph.py --tb=short -q: 29 passed
• pytest --tb=short -q: 267 passed
• ruff check src\archunitpython\common\extraction\graph.py src\archunitpython\common\extraction\extract_graph.py tests\common\test_extract_graph.py: passed
• mypy src\archunitpython\ --ignore-missing-imports: passed
• git diff --check: passed

Note: full ruff check src tests still reports existing baseline cleanup issues, which are handled separately in #31.

[lukasniessen-bain]

I found one blocker around relative conditional imports.

from . import fallback inside a handled ImportError block is now classified as CONDITIONAL_IMPORT, but the resolver only has the stored import name '.' to work with. That means the graph resolves the package path rather than the sibling module being imported. This is a common optional fallback pattern, so it can silently produce the wrong dependency edge for the exact behavior this PR is adding.

Please add coverage for conditional relative imports, especially from . import module, and adjust the extraction/resolution path so the conditional context does not erase the relative import semantics needed to resolve the target correctly.

[TristanKruse]

@copilot resolve the merge conflicts in this pull request

[TristanKruse]

@copilot resolve the merge conflicts in this pull request

[TristanKruse]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Resolved by merging origin/main into this branch and fixing the BACKLOG.md conflict in commit 13a8e50.

[Copilot]

@copilot resolve the merge conflicts in this pull request

Already resolved in 13a8e50; branch is currently clean and up to date with origin/main.

@copilot resolve the merge conflicts in this pull request

Already resolved in 13a8e50; branch is currently clean and up to date with origin/main.

[lukasniessen-bain]

One blocker before merge:

_import_from_module_names now rewrites every from . import a, b to .a / .b, including non-conditional ones. When the alias isn't a module file — e.g. from . import VERSION where VERSION lives in init.py, a C-extension sibling, or a namespace package — _resolve_relative_import falls through to return (candidate_base + ".py", True), so we emit an external edge whose target is an absolute filesystem path, and we lose the internal init.py edge we used to produce. That label is used verbatim by per_external_edge, project_nodes(include_externals=True), and the CSV/HTML rows, so it can produce false external-dependency violations. Please fall back to the package target when . doesn't resolve, and add a regression test for from . import .

Two non-blocking notes:

Conditional edges now carry two kinds (e.g. relative|conditional), so the import_kinds column in graph reports changes shape for existing projects. Worth a line in the README/changelog since report consumers may parse it.
CONDITIONAL_IMPORT is still listed in the relative branch of _resolve_import, but _resolve_import is now always called with resolution_kind, so that arm is unreachable — fine to drop for clarity.