Hacker News Reader

Comment by kibwen | Hacker News Reader

The problem described in the post isn't the fault of package naming schemes, it's due to `pip install --extra-index-url` apparently ignoring the user-specified registry if the package exists on PyPI, which, if true, is baffling, because it throws out the concept of private registries altogether in favor of treating PyPI as some sort of universal namespace.

View on HN

> due to `pip install --extra-index-url` apparently ignoring the user-specified registry if the package exists on PyPI

I thought this was the expected behavior of --extra-index-url

To force pip to use a user-specified registry, you would use --index-url instead of --extra-index-url

We ran into a pretty serious vulnerability around editable installs last year as well. Nearly the same story as here - basically an editable install hit an edge case and went to pypi instead when you wouldn’t expect it to. Python has not thought this problem through nearly as much as the Java people have.

> The problem described in the post isn't the fault of package naming schemes

If PyPI used Java-like scheme with domain ownership verification, Google would presumably use com.google.* namespace for their private stuff and it wouldn’t be possible to introduce malicious package this way.

So the described issue arguably is a consequence of that.

That Github issue is insane. So frustrating that an obviously wrong behavior is continued even after exploits in the wild. Count me as one of those idiot users who was confused by the current behavior.

To be fair, the parameter is called extra index url, not private index url.

That there is no other option for private repositories or namespacing is still a big shame.

There is, as already pointed out in a sibling comment, and it's called --index-url: https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-0

Reply on news.ycombinator.com