Skip to content

ci: make isort is red on main (pcapkit/protocols/schema/schema.py) #757

Closed

Description

@JarryShaw

Describe the bug

make isort is red on main: pcapkit/protocols/schema/schema.py has imports isort wants reformatted.
CONTRIBUTING.md lists make isort among the checks a contributor is asked to run, so it currently fails
on a clean checkout through no fault of the change under test.

Reproduction

On 73f09aecb:

$ python -m isort --check-only --diff pcapkit/protocols/schema/schema.py
ERROR: pcapkit/protocols/schema/schema.py Imports are incorrectly sorted and/or formatted.
@@ -10,19 +10,22 @@
-from pcapkit.corekit.fields.misc import ConditionalField, ForwardMatchField, PayloadField
+from pcapkit.corekit.fields.misc import (ConditionalField, ForwardMatchField,
+                                         PayloadField)

Expected behavior

Either the file is reformatted so make isort is clean, or isort's configuration is adjusted to accept the
single-line form. The one-line import is 89 characters, and the project's own line-too-long threshold is
120 — so isort's wrap width appears to disagree with the linter's, which is the more likely root cause and
the more durable fix.

System information

  • OS Version: Linux 5.10 (Amazon Linux 2 int)
  • Python Version: 3.14.7
  • Python Implementation: CPython
  • pcapkit Version: checkout at 73f09aecb

Additional context

Found while cross-reviewing #752 — identical on both trees, so unrelated to that PR. Worth noting it is not
alone: lint.yml's own header records bandit, mypy, vermin and pylint all exiting non-zero, which
is why none of them gates a merge (see #753 for that comment's figures having drifted). So this is one
instance of a broader "the documented checks do not pass on main" situation, and fixing it in isolation
does not make make lint green.

Activity

  1. added
    bugIssues reporting a defect (set by the bug report template; a default, not an assessment)
    ciPull requests that change CI or workflow configuration (ci: subject prefix)
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Sep 24, 2026
  2. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Sep 25, 2026
  3. added this to the 1.5 milestone on Oct 6, 2026
  4. moved this to Done in PyPCAPKiton Oct 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugIssues reporting a defect (set by the bug report template; a default, not an assessment)ciPull requests that change CI or workflow configuration (ci: subject prefix)

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions