Skip to content

refactor!: remove every surviving re-export of a moved name or module #1744

Closed

Description

@JarryShaw

Is your feature request related to a problem? Please describe.
The owner's rulings on #1103 (2026-10-14): TLSKeyLabel keeps no fallback re-export, and no moved name or module keeps any re-export. #1715's no-re-export rule was applied to every move made after it, but a few re-exports from earlier moves survive. The #1103 inventory found these:

Describe the solution you'd like
Take a complete inventory of every name or module that moved in 1.5.0 and is still importable from its old path. Remove each of those paths and point every reader at the new home. A path that shipped in a 1.4.x release gets versionremoved:: 1.5.0; a name that existed only in the betas gets none, per the same ruling. The change is breaking. A guard test then fails on any old path that is still importable.

Activity

  1. added
    breakingBreaks public-facing behaviour or API (apply alongside the type label)
    refactorRestructuring for its own sake — neither a fix nor a new capability (refactor: prefix)
    pendingAccepted and unstarted - nobody is on it and nothing blocks it
    on Oct 14, 2026
  2. moved this to Pending in PyPCAPKiton Oct 14, 2026
  3. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    pendingAccepted and unstarted - nobody is on it and nothing blocks it
    on Oct 14, 2026
  4. moved this from Pending to WIP in PyPCAPKiton Oct 14, 2026
  5. JarryShaw commented on Oct 14, 2026

    @JarryShaw
    OwnerAuthor

    Inventory, read-only, on main at 0cdd3cdd1. 18 old paths still resolve. 7 shipped in 1.4.x and get versionremoved:: 1.5.0: TLSKeyLabel, field.NoValueType, registry NULL, httpv1._RE_*, byteorder_callback ×2, and tcp/udp PortEnumField. 11 are beta-only and get deleted outright: the NO_VALUE/NO_DEFAULT/NULL/ABSENT sentinel re-exports, DeferredPacket ×3, the NGAP aliases, and four schema helpers.

    Five questions first, with the default I'd take:

    # Question Default
    D1 Nine of the paths are incidental: the module imports the name for its own use, so the old path resolves only as a side effect. An example is schema.misc.pcapng.byteorder_callback, which is used 82 times. Do they count? Yes: import the module, not the name, so the old path stops resolving
    D2 corekit.module._get_null is a pickle shim, not a re-export. Only 1.5.0b5/b6 could have written pickles that need it Remove it, since betas count toward the next release
    D3 Package aggregations whose home moved inside the package: const.reg.apptype.AppType (79 readers), reassembly.data.ReassemblyData, traceflow.data.TraceFlowData Keep them; they are the documented package paths
    D4 Registry NULL was the string '(null)' in 1.4.x and is now the sentinel, so it is a different object versionchanged, not versionremoved
    D5 Private _RE_* names shipped in 1.4.x No directive for private names

    This also overturns #911's per-module re-export design, written up in sentinel-convention.rst:38-44 and the corekit/sentinels.py docstring. Both get rewritten. The removal PR starts after #1739 lands, because it edits the same protocols/** files.

  6. added
    needs: decisionWaiting on the maintainer to decide — not blocked by other work
    on Oct 14, 2026
  7. moved this from WIP to Needs decision in PyPCAPKiton Oct 14, 2026
  8. JarryShaw commented on Oct 14, 2026

    @JarryShaw
    OwnerAuthor

    D1 - from new_module import name is fine and the exposure is expected.
    D2 - remove if they're no longer used by the library
    D3 - what's exactly moved? i think D1 should still answer this.
    D4 - versionchanged
    D5 - since private and not added in Sphinx docs, no need to add directives

  9. JarryShaw commented on Oct 14, 2026

    @JarryShaw
    OwnerAuthor

    Recorded:

    • D1: an ordinary from new_module import name stays. The old path resolving through it is expected, so the nine incidental entries (3–7, 15–18) are kept.
    • D2: _get_null goes if nothing in pcapkit still uses it. Tests and pickle compatibility don't count.
    • D3: covered by D1. const.reg.apptype and the reassembly/traceflow data packages import from their own submodules, so they stay. What moved there:
    • D4: registry NULL gets versionchanged:: 1.5.0. It was the string '(null)' in 1.4.x and is now the sentinel.
    • D5: private names not in the Sphinx docs get no directive.

    That leaves the explicit re-exports to remove:

    • the TLSKeyLabel alias;
    • the NGAP ProcedureCode and ProtocolIE aliases;
    • NO_VALUE in corekit.fields.field's __all__, NO_DEFAULT in corekit.enum's, and NULL in corekit.module's;
    • ABSENT in protocols.protocol, which is documented as a re-export;
    • DeferredPacket from the three __all__ lists;
    • _get_null, unless the library still uses it.

    sentinel-convention.rst is rewritten to match: consumers import from corekit.sentinels, and never list a sentinel in their own __all__ or document it as theirs. This starts once #1739 merges, because both edit protocols/misc/pcapng.py.

  10. added
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    and removed
    needs: decisionWaiting on the maintainer to decide — not blocked by other work
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 14, 2026
  11. moved this from Needs decision to Blocked in PyPCAPKiton Oct 14, 2026
  12. JarryShaw commented on Oct 15, 2026

    @JarryShaw
    OwnerAuthor

    A worker is on this, stacked on #1752's branch because both edit protocols/misc/pcapng.py. Its PR opens once #1752 merges and the branch is rebased onto main. Scope per D1–D5: only explicit re-exports go (inventory #1, #2, #8–#14, plus the D4 directive on #3), and the incidental imports stay.

  13. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 15, 2026
  14. moved this from Blocked to WIP in PyPCAPKiton Oct 15, 2026
  15. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 15, 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

    breakingBreaks public-facing behaviour or API (apply alongside the type label)refactorRestructuring for its own sake — neither a fix nor a new capability (refactor: prefix)

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions