pytorch - 💡(How to fix) Fix [RFC] Best practices for backend installations requiring +cpu / non-PyPI wheels [1 comments, 2 participants]

I am opening this RFC to seek guidance and establish a standard recommendation for installing third-party PyTorch backends (e.g., torch-rbln) that depend on specific PyTorch builds (such as torch==2.9.1+cpu) hosted on download.pytorch.org.

The Problem

Since specialized builds like +cpu are not available on PyPI, downstream backends currently face a dilemma between user convenience and supply chain security:

1. The --extra-index-url approach (Common but insecure): pip install torch-rbln --extra-index-url https://download.pytorch.org/whl/cpu This provides a seamless UX but opens the door to Dependency Confusion attacks, as pip searches both indices for all packages during resolution.

2. The Two-Step --index-url approach (Secure but cumbersome): pip install torch==2.9.1+cpu --index-url https://download.pytorch.org/whl/cpu pip install torch-rbln This safely restricts pip to the intended index but introduces significant friction for end-users and CI/CD environments.

Discussion Points

As an increasing number of hardware-accelerated backends encounter this split-index issue, an official stance from the PyTorch packaging team would significantly benefit the ecosystem.

• Should backend maintainers explicitly mandate the two-step installation in their documentation to prioritize security, despite the UX degradation?
• Are there any planned packaging mechanisms, standardized pip workflows, or official tooling to handle these non-PyPI dependencies safely without exposing users to risks?

We welcome insights from the community and packaging experts on establishing a secure and unified best practice for the broader PyTorch ecosystem.

cc @seemethere @malfet @atalman @tinglvv @nWEIdia @NmomoN @mengpenghui @fwenguang @cdzhan @1274085042 @PHLens @albanD