Disallow packages with the same name as stdlib modules

[Erik Bray]

Hi all,

Sorry if this has come up before--I don't remember if it has. A recent
question on StackOverflow [1] alerted to me to the fact that there is
a package named "os" on PyPI: https://pypi.python.org/pypi/os

*Thankfully* it is:

a) Malformed--the package tarball isn't built correctly and it doesn't
install with pip
b) Not (currently!) evil: It just raises a RuntimeError telling you
not to "pip install os"

That said, I think such packages should be prevented from being
uploaded at all. Naturally, the list of stdlib modules is a moving
target, but not *that* fast-moving.

Conversely, I don't think new modules added to the stdlib should use
the name of a package on PyPI, or at least should be prevented from
being uploaded for Python versions equal to or later than the version
in which that module was added to the stdlib.

Thanks,
Erik


[1] https://stackoverflow.com/questions/46853112/python-pip-install-os-windows-errno-2

[Donald Stufft]

Sorry for the delay in response.

So we actually *do* disallow package names with the same name as stdlib modules, however because there are a number of them that exist today and are useful (asyncio, ssl, etc) the way we’ve implemented this is that *new* projects cannot be created with the same name as stdlib modules, but existing projects can continue to use their names. This also allows the PyPI admins to selectively give someone the same name as a stdlib module if needed.

Just to close the loop on this, I believe the ones identified here have all be removed from PyPI along with several others by the same author. If you come across any others feel free to point them out.

[Erik Bray]

Hi Donald,

On Wed, Oct 25, 2017 at 6:52 PM, Donald Stufft <don...@stufft.io> wrote:
> Sorry for the delay in response.

No problem, I know how overwhelmingly busy you are.

> So we actually *do* disallow package names with the same name as stdlib modules, however because there are a number of them that exist today and are useful (asyncio, ssl, etc) the way we’ve implemented this is that *new* projects cannot be created with the same name as stdlib modules, but existing projects can continue to use their names. This also allows the PyPI admins to selectively give someone the same name as a stdlib module if needed.

Okay, thanks for the explanation of the policy. That makes perfect sense.

> Just to close the loop on this, I believe the ones identified here have all be removed from PyPI along with several others by the same author. If you come across any others feel free to point them out.

Thanks!

Best,
Erik

[Wes Turner]

There was an ANN for this issue:

[Python-Dev] SK-CSIRT identified malicious software libraries in the official Python package repository, PyPI
https://mail.python.org/pipermail/python-dev/2017-September/149569.html

[Security-announce] Typo squatting and malicious packages on PyPI
https://mail.python.org/pipermail/security-announce/2017-September/000000.html

And GitHub issues:

Can register packages that match system packages
https://github.com/pypa/pypi-legacy/issues/585

Block package names that conflict with core libraries
https://github.com/pypa/warehouse/issues/2151