Skip to content

refactor(registry): split foundation.registry.protocols into registry.protocols.<layer> submodules #2578

Closed

Description

@JarryShaw

From the owner on #2511: consider splitting pcapkit/foundation/registry/protocols.py, which holds 56 register_* wrappers, the shared validators (_check_code, _register_name, _NameLease, _MISSING) and register_protocol/register_protocol_code. Name any submodules registry.protocols.<submodule>, following pcapkit.protocols.

Decision needed:

  1. Granularity. (a) Per layer: registry/protocols/{link,internet,transport,application,misc}.py, mirroring pcapkit.protocols' layer subpackages. (b) Per protocol: one module per owning class, roughly 40 small files. (c) Leave the file whole.
  2. Shared helpers. (a) A base module, registry/protocols/protocol.py, after pcapkit.protocols.protocol's framework base, holding the validators plus register_protocol and register_protocol_code. (b) A private _common.py.
  3. Public paths. The package __init__ aggregates its submodules (refactor!: remove every surviving re-export of a moved name or module #1744 D3), so pcapkit.foundation.registry.protocols.register_tcp and pcapkit.foundation.registry.register_tcp keep resolving. The definitions move, so __module__ and the docs' cross-reference targets change.

Recommendation: 1(a), 2(a), 3 as stated. Per-layer files are a size a reader can scan. Per-protocol files would mostly hold one function each, and #2534's per-protocol packages could absorb them later if wanted.

Timing: one mechanical move with no behaviour change, after #2527 and #2544 merge, since both edit this file.

Activity

  1. added
    refactorRestructuring for its own sake — neither a fix nor a new capability (refactor: prefix)
    needs: decisionWaiting on the maintainer to decide — not blocked by other work
    on Nov 1, 2026
  2. moved this to Needs decision in PyPCAPKiton Nov 1, 2026
  3. JarryShaw commented on Nov 1, 2026

    @JarryShaw
    OwnerAuthor

    Take all recommendations

  4. JarryShaw commented on Nov 1, 2026

    @JarryShaw
    OwnerAuthor

    Owner took all three recommendations, paraphrased:

    1. Per layer: pcapkit/foundation/registry/protocols/ becomes a package with link.py, internet.py, transport.py, application.py and misc.py.
    2. Shared helpers: they go in a base module, registry/protocols/protocol.py, after pcapkit.protocols.protocol. That covers _check_code, _register_name, _NameLease, _MISSING, register_protocol and register_protocol_code.
    3. Public paths stay: the package __init__ aggregates its submodules (refactor!: remove every surviving re-export of a moved name or module #1744 D3).

    It is one mechanical move with no behaviour change. Blocked: #2527 and #2544 both edit this file, so this unblocks when both merge.

  5. 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
    on Nov 1, 2026
  6. moved this from Needs decision to Blocked in PyPCAPKiton Nov 1, 2026
  7. JarryShaw commented on Nov 1, 2026

    @JarryShaw
    OwnerAuthor

    #2527 and #2544 have merged, but several branches add wrappers to registry/protocols.py: #2575, #2533, #2489, #2514 and #2555. A package split now would conflict with every one of them. Blocked: this unblocks when those five PRs merge.

  8. added this to the PyPCAPKit v1.6 milestone on Nov 2, 2026
  9. JarryShaw commented on Nov 2, 2026

    @JarryShaw
    OwnerAuthor

    The five PRs that added wrappers to registry/protocols.py (#2575, #2533, #2489, #2514 and #2555) have all merged. Unblocked. A worker is splitting the module into per-layer submodules. The move is mechanical: every registrar stays the same object, and the name resolution is listed in the PR.

  10. 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 Nov 2, 2026
  11. moved this from Blocked to WIP in PyPCAPKiton Nov 2, 2026
  12. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Nov 2, 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

    refactorRestructuring for its own sake — neither a fix nor a new capability (refactor: prefix)

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions