Skip to content

fix(foundation): let the pypcap engine fall back when the pcap module cannot load (#2132) - #2133

Merged
JarryShaw merged 1 commit into
mainfrom
fix/2132-pypcap-unusable-module
Oct 24, 2026
Merged

JarryShaw merged 1 commit into
mainfrom
fix/2132-pypcap-unusable-module

Conversation

@JarryShaw

Copy link
Copy Markdown
Owner

What is the purpose of your pull request?

  • fix — corrects a defect

Description of your pull request and other information

Closes #2132.

  • Bug: when the pcap module is installed but cannot load (OSError from its loader), extract(engine='pypcap') raised the error. engine='pcap_ct' warned and fell back. PyPCAP._reason_for only checked wrong_backend_reason.
  • Fix: both engines' _reason_for now call a new _pcap_backend.engine_reason(wanted, found), so they cannot drift apart. It returns the wrong-backend reason, or PCAP_CT's existing "installed but unusable -- " wording, or None when the module is absent, which the import test already reports.
  • Constructor: the PyPCAP.__init__ backstop raises UnsupportedCall rather than letting the OSError out of import pcap.
  • Docs: an engine_reason entry in 3rdparty.rst, and the "declines to run" bullet in engines/index.rst.
  • Tests: tests/foundation/engines/test_pypcap_unusable_module_2132_unit.py.
    • It covers the helper, plus a child interpreter with a fake pcap that raises OSError('Cannot find libpcap.so library'). In the child, both engines must warn and fall back.
    • Against main: 8 failed, 2 passed. The passing pcap_ct case is the control.
    • With the fix: 8 passed. The foundation ordering leg gives 738 tests, 0 failures.

@JarryShaw JarryShaw added bug Issues reporting a defect (set by the bug report template; a default, not an assessment) review: running A cross-review is in flight against the current head - no verdict yet labels Oct 24, 2026
@JarryShaw JarryShaw added the review: running A cross-review is in flight against the current head - no verdict yet label Oct 24, 2026
… cannot load (#2132)

- Add _pcap_backend.engine_reason(): the wrong-backend verdict plus the
  installed-but-unusable one PCAP_CT already gave.
- PyPCAP._reason_for and PCAP_CT._reason_for both return it, so
  extract(engine='pypcap') now warns and falls back to the default engine
  instead of raising the loader's OSError, and the two cannot drift again.
- Document the new verdict in PyPCAP's docstrings and the engines docs.

Tests: tests/foundation/engines/test_pypcap_unusable_module_2132_unit.py,
with a fake pcap package raising OSError in a child interpreter; fails on
origin/main, passes here, foundation leg green.
@JarryShaw

Copy link
Copy Markdown
Owner Author

GOOD TO GO at fe72cfa03 (Sonnet review of cdff40b57, plus its one nit, now applied).

  • Shared verdict: _pcap_backend.engine_reason keeps PCAP_CT's verdicts exactly; I diffed the old body against the new. wrong_backend_reason still takes precedence. An absent module still returns None for the import test.
  • Extraction: Extractor warns and falls back on the new reason before PyPCAP.__init__ runs. The __init__ backstop's UnsupportedCall is visible only to someone constructing the engine directly.
  • Tests: 6 of the 8 new tests fail on main's three engine files. The pcap_ct end-to-end case passes there, as the control. The child-interpreter test asserts it runs the PR's pcapkit.
  • Nit applied: fe72cfa03 changes only engine_reason's docstring. It drops the history sentences and keeps the contract with :issue:`2132` . The range-diff shows nothing else.

@JarryShaw
JarryShaw force-pushed the fix/2132-pypcap-unusable-module branch from cdff40b to fe72cfa Compare October 24, 2026 02:22
@JarryShaw JarryShaw added review: good-to-go Cross-review at the current head says ready; CI state is separate and removed review: running A cross-review is in flight against the current head - no verdict yet labels Oct 24, 2026
@JarryShaw JarryShaw moved this to In review in PyPCAPKit Oct 24, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Coverage: 91.55% (unit tier, Python 3.15, fe72cfa03, Unit Tests run success)

Package Statements Missed Branches Partial Cover
pcapkit (top level) 104 4 20 2 95.16%
pcapkit/const 19599 880 2618 866 92.12%
pcapkit/corekit 2589 75 816 37 96.48%
pcapkit/dumpkit 282 3 102 3 98.44%
pcapkit/foundation 2971 23 1036 25 98.80%
pcapkit/interface 138 4 52 3 96.32%
pcapkit/protocols 17418 219 4574 185 98.14%
pcapkit/toolkit 869 36 298 10 95.20%
pcapkit/utilities 498 7 144 5 98.13%
pcapkit/vendor 4432 1988 1018 167 51.87%

Per-file detail: the coverage-html artifact of this run.

@JarryShaw

Copy link
Copy Markdown
Owner Author

Ready to merge at fe72cfa03.

  • Review: the Sonnet review is GOOD TO GO, and its docstring nit is applied.
  • CI: every blocking check passed (Required checks passed SUCCESS), and the 3.8–3.10 KTLO legs carry no warnings.
  • Ordering: the head sits directly on main 8fdc2fb33. Its tests/foundation plain-unittest ordering leg ran 738 tests with 0 failures, on the code this head carries; only a docstring changed since.

This closes #2132.

@JarryShaw
JarryShaw merged commit ad71ef5 into main Oct 24, 2026
62 checks passed
@JarryShaw
JarryShaw deleted the fix/2132-pypcap-unusable-module branch October 24, 2026 04:34
@github-project-automation github-project-automation Bot moved this from In review to Done in PyPCAPKit Oct 24, 2026
@JarryShaw JarryShaw removed the review: good-to-go Cross-review at the current head says ready; CI state is separate label Oct 24, 2026
@JarryShaw JarryShaw added this to the PyPCAPKit v1.5 milestone Oct 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Issues reporting a defect (set by the bug report template; a default, not an assessment)

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

fix(foundation): the pypcap engine raises a pcap loader's OSError instead of falling back as pcap_ct does

1 participant