[cleonard530]

Description

DeepGEMM’s native MLOPart bridge hardcoded deep_gemm.utils.mlopart, which fails when DeepGEMM is vendored under another package name such as vllm.third_party.deep_gemm.
This change:

• Passes the active Python package name during initialization.
• Resolves utils.mlopart relative to that package.
• Keeps torch.ops.deep_gemm.init(path) backward compatible by defaulting the package name to deep_gemm.

Testing

• Forced extension rebuild completed successfully.
• Verified standard deep_gemm import.
• Verified legacy one-argument torch.ops.deep_gemm.init(path).
• Verified native MLOPart lookup resolves through a synthetic vendored package.

I think this will need to go through before vllm-project/vllm#61149 can be merged into vllm.

Co-authored-by: codex
reviewed by @cleonard530

cc @Harry-Chen @janeyx99

[zyongye]

Hi @cleonard530 could you check if #31 has solve the issue? Thanks

Edit:
ok I guess not. I will let @Harry-Chen and @janeyx99 to review

[zyongye]

While checking whether anything else in the tree made the same package-name assumption, I found one more that would fit naturally in this PR.

deep_gemm/_C.py builds the locality_domain shim as f'{__name__}.locality_domain' so the name follows the package, but the epilogue shim a few lines above still hardcodes it:

-epilogue = types.ModuleType('deep_gemm.epilogue', 'GEMM epilogue classes')
+epilogue = types.ModuleType(f'{__package__}.epilogue', 'GEMM epilogue classes')

Nothing breaks today: epilogue is reached as an attribute and is never registered in sys.modules, so the stale name only shows up in repr()/help(). It would turn into a real phantom deep_gemm.epilogue entry for anyone who later mirrors the sys.modules registration that locality_domain has. __package__ keeps the name identical for a normal install and tracks the vendored package otherwise — verified on top of this branch:

import	before	after
import deep_gemm	deep_gemm.epilogue	deep_gemm.epilogue
vendored under another package	deep_gemm.epilogue	<vendored>.epilogue

I would have pushed it to this branch directly — maintainer_can_modify is enabled — but your fork's parent is deepseek-ai/DeepGEMM, so admin on the sibling vllm-project/DeepGEMM doesn't grant maintainer-edit access there (403). Feel free to take the one-liner, or I can send it as a follow-up PR if you'd rather keep this one focused.

For what it's worth, the rest of the audit came back clean, and this PR does fix the real thing:

• mlopart.hpp:88 was the only hardcoded Python import in csrc/; after this PR there are none.
• The MLOPart server spawn already used [sys.executable, '-I', __file__, ...] rather than -m, so it was vendoring-safe.
• Every internal import in the package is relative.
• Reproduced the failure on current dev by importing the package under another name: RuntimeError: Assertion error (csrc/runtime/mlopart.hpp:62): MLOPart Python call failed: No module named 'deep_gemm'. With this branch built, the same test returns is_localization_available() -> True, and both import deep_gemm and the legacy one-arg torch.ops.deep_gemm.init(path) still work.

[cleonard530]

Feel free to take the one-liner, or I can send it as a follow-up PR if you'd rather keep this one focused.

I'll update this real quick