Skip to content

fix(conda): vendored dependencies ship without their data files #1814

Closed

Description

@JarryShaw

Describe the bug
The conda package's vendored dependencies (pcapkit/_extern, installed by conda/pypcapkit/build.sh and bld.bat from conda/requirements.txt) reach the wheel only as .py modules, through package discovery. Their data files never ship: for example certifi/cacert.pem, pyshark/config.ini, emoji's JSON data, lxml's compiled extensions and every dist-info. This was found by emulating the recipe (pip install --target of the requirements, then pip wheel .), before and after #1813. A real conda build was not available to confirm it.

If the emulation holds, vendored requests has no CA bundle, and pyshark and emoji lack files they read at runtime.

Expected behavior
A conda-built pcapkit ships each vendored dependency complete, and a smoke test in the conda workflow imports and exercises them.

Additional context
Found by #1794's worker and confirmed by its Sonnet review, which also showed that recursive-include pcapkit/_extern * would add the missing files but warns in every non-conda build. The new MANIFEST.in guard from #1813 would need to allow an include whose target is git-ignored. Fix routes: MANIFEST.in, package-data, or the recipe scripts.

Activity

  1. added
    fixPull requests that fix a defect (fix: subject prefix)
    pendingAccepted and unstarted - nobody is on it and nothing blocks it
    on Oct 16, 2026
  2. JarryShaw commented on Oct 16, 2026

    @JarryShaw
    OwnerAuthor

    Blocked until #1813 merges; it rewrites MANIFEST.in and adds the guard any fix here has to satisfy.

  3. added
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    and removed
    pendingAccepted and unstarted - nobody is on it and nothing blocks it
    on Oct 16, 2026
  4. moved this to Blocked in PyPCAPKiton Oct 16, 2026
  5. JarryShaw commented on Oct 16, 2026

    @JarryShaw
    OwnerAuthor

    We should probably review what're the needed 3p vendored dependencies for Conda distros. I suppose that list is stale.

  6. JarryShaw commented on Oct 16, 2026

    @JarryShaw
    OwnerAuthor

    Unblocked: #1813 has merged. Scope widened, per your note: first audit which third-party packages a conda build actually needs vendored, since conda/requirements.txt is likely stale against pyproject.toml, and drop or update the stale ones. Then make the ones that stay ship complete, data files included. A worker is on it. No conda toolchain is available here, so the build will be emulated.

  7. 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 16, 2026
  8. JarryShaw commented on Oct 16, 2026

    @JarryShaw
    OwnerAuthor

    And also, might wanna automate the audit/update of the list - as the project grows and its dependencies update.

  9. JarryShaw commented on Oct 16, 2026

    @JarryShaw
    OwnerAuthor

    Added to the worker's scope: a util/ script that derives the vendored list from pyproject.toml and rewrites conda/requirements.txt, plus a check that fails when the file goes stale. The check will be wired into the conda workflow, or into a scheduled updater like the python-versions one from #1660. All of it lands in the same PR.

  10. moved this from Blocked to WIP in PyPCAPKiton Oct 16, 2026
  11. JarryShaw commented on Oct 16, 2026

    @JarryShaw
    OwnerAuthor

    #1821 is up, and it needs one call from you on what the conda package vendors.

    I recommend A. Switching later is one line (EXTRAS in util/conda_vendor.py).

    Separately, the macOS conda convert step ships arm64 binaries for osx-64. This already broke lxml, and with A it also affects cffi and cryptography. I'd file that as its own issue.

  12. added
    needs: decisionWaiting on the maintainer to decide — not blocked by other work
    on Oct 16, 2026
  13. JarryShaw commented on Oct 16, 2026

    @JarryShaw
    OwnerAuthor

    take A

  14. JarryShaw commented on Oct 16, 2026

    @JarryShaw
    OwnerAuthor

    Recorded: option A, which is what #1821 already does: dependencies plus the all extra. The osx-64 binary problem is now #1822, blocked behind #1821.

  15. removed
    needs: decisionWaiting on the maintainer to decide — not blocked by other work
    on Oct 16, 2026
  16. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 16, 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

    fixPull requests that fix a defect (fix: subject prefix)

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions