gpo.zugaina.org

Search Portage & Overlays:

dev-python/torch-c-dlpack-ext

Companion DLPack C-exchange-API ext for older torch builds

Screenshots

  • torch-c-dlpack-ext-0.1.5
    ~amd64
    python_targets_python3_11 python_targets_python3_12 python_targets_python3_13 python_targets_python3_14

    View      Download      Browse     License: Apache-2.0   
    Overlay: stuff

ChangeLog

commit c559fd63f77ce9b5b533af83e8b26a2a2d1af7d4
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu May 7 14:39:08 2026 +0200

dev-python/torch-c-dlpack-ext: new package, 0.1.5

Tier 0 leaf for the vllm CUDA target packaging cycle. Companion
DLPack C-exchange-API ext for older torch builds: at wheel build
time, the upstream build_backend.py inspects the installed torch and
either ships pure-Python (modern torch already exposes
__dlpack_c_exchange_api__) or compiles a native .so against the
detected CUDA/ROCm runtime via tvm_ffi.utils._build_optional_torch_c_dlpack.
Used by tilelang and quack-kernels as a transitive build dep.

Two ebuild-side fixes:

* Upstream's [tool.setuptools] py-modules = ["build_backend"] would
ship the PEP 517 backend wrapper at the top of site-packages —
literally /usr/lib/pythonX.Y/site-packages/build_backend.py, a
generic-named module shadowing anything else of that name and
pulling in setuptools at runtime. Drop it in python_install_all
rather than carry a one-line pyproject.toml patch.

* apache-tvm-ffi declared as a defensive BDEPEND even though our
current torch has the dlpack-c API and the native build is skipped:
a future torch downgrade would need it and the cost is zero (we
package it ourselves now).

Accepting the NonsolvableDepsInStable false positive from
sci-ml/pytorch's ~amd64-only keyword (same shape as xgrammar etc.).