A lot of the variants here seem to be still requiring/implying some level of verification from pypi, and even if resources are allocated to making that happen, I don’t think these will work well with multiple index use.
This was pointed out in the 752/755 discussions already:
There are multiple things pointing to this part of the problem being in scope for organizations that would benefit from it. an index server that sidesteps this issue by merging multiple index servers and prefers packages based on the order the mirror is told has recently been open-sourced by developers at CERN, whose motivations are quotable as:
Dependency confusion here was specifically in the context of multiple index servers. The full details and links to history surrounding that are in the full quoted post, and I do encourage others to go read it.
With that and many other problems in mind, I don’t think we should be building something that relies on pypi admin review for this specific problem. There’s a benefit here that such solutions also don’t need to pass as much of a hurdle as they don’t suggest an ongoing new admin cost or an ongoing additional reliance on funding surrounding a solution that we may not want in the future. Still, even if money and time were magically not a concern, pypi admins can’t know what might exist on all other indexes that any kind of package might clash with, either maliciously or unintentionally.
If the goal is making sure users don’t accidentally find themselves installing an unexpected (not even necessarily maliciously so) dependency, then I think the ssh model on this is the clearest, especially if we pair it with a new extension to dependency specifiers that asserts “this came from this user on this index”, a way to have a user-configured store of trust, and allow scoping trust as “globally trusted”, “trusted for this project”, or “trusted for this dep in this project” (the last of which is what is used when the new dependency specifier is explicitly used)