[Build] Revert triton_kernels requirements

[varun-sundar-rabindranath]

Purpose

Revert part of #27370

Adding this triton_kernels as dependency seems to break wheel installation.

(new) coder@4xl40s devspaces (main) $ uv pip install vllm --extra-index-url https://wheels.vllm.ai/nightly
Using Python 3.12.11 environment at: new
  × Failed to resolve dependencies for `vllm` (v0.11.1rc4.dev17+g361a7463d.cu129)
  ╰─▶ Package `triton-kernels` was included as a URL dependency. URL dependencies must be expressed as direct requirements or constraints.
      Consider adding `triton-kernels @ git+https://github.com/triton-lang/[email protected]#subdirectory=python/triton_kernels` to your
      dependencies or constraints file.

Solve : #27573

Test Plan

Test Result

[gemini-code-assist]

Code Review

This pull request reverts the addition of the triton_kernels dependency to fix a critical installation issue encountered with uv. While this change correctly addresses the installation problem, it also removes a dependency required for mxfp4 fused moe functionality, as indicated by the removed comment. This will likely break that feature. My review comment highlights this trade-off and suggests that this side effect be documented in the pull request description. For a long-term solution, I've recommended considering making this an optional dependency to avoid breaking the build for users who do not require this specific feature.

[varun-sundar-rabindranath]

cc @zyongye

[zyongye]

I wonder what is the correct way to add a dependency like this?

[cjackal]

Apparently this type of direct URL dependency in a package is forbidden by PyPI for security reason; downloading from an untrusted(non-PyPI, that is) domain must be triggered by the end user, not by a hidden dependency.

So the solution would be like building the wheel and uploading to a proper wheel index, I think.

[simon-mo]

Wheel installation requires all packages in same registry (PyPI).

Let's vendor the code.

[noooop]

unblock buildkite/ci/pr/language-models-test-extended-pooling

---

this pr work great with pooling models

[varun-sundar-rabindranath]

@simon-mo This is the previous build-kite run, https://buildkite.com/vllm/ci/builds/36673#019a2e0d-01c0-4071-b17d-d1c66f9efe02
It fails the LoRA tests and the Quantization tests. I rebased the branch to latest main to trigger the current run.

I saw your comment on #27598 (comment) mentioning LoRA and Quantization nightly failures. Maybe it is okay to force-merge this PR ?

[simon-mo]

Oh this is a revert to unbreak main, happy to force merge