There's still a `logging` package on PyPI, owned by the standard library implementor, and it apparently can cause problems

The other day, I discovered a case where someone had apparently managed to install the PyPI logging module into a Python 3.12 environment, thereby breaking Pipenv.

Of course, there has been a standard library logging package for over 20 years now; so I figured this had to be either something unrelated that managed to sneak in before the 2017 changes to PyPI name policy (and specific blocking of such names) - perhaps even before the 2012 PEP guidance - or else a backport. Instead, as far as I can tell, it’s the original implementation of the standard library module used to support that PEP - which was patched a couple times in 2004 and then once more in 2013, all after being integrated into the Python standard library (and if there were older versions, they aren’t available any more).

Curiously enough, the logging package installs perfectly fine into a Python 3.12 virtual environment, even though it’s sdist-only. It’s pure Python; and while the installed code is 2.x-only, the bare-bones setup.py is compatbile with modern Python. It doesn’t have any trove classifiers, nor a python_requires argument in the setup call (would Distutils/Setuptools have recognized that back in the day?), but Pip is permissive by default here.

Normally, installing this still shouldn’t cause a problem since the standard library will be ahead of the site-packages folder on sys.path; but apparently something went wrong in that specific case on Stack Overflow. It’s a risk that shouldn’t be taken, as it comes with zero benefit. (I think? Have I overlooked anything?)

This package is getting thousands of downloads a day - about six times as many as turtle, the case that brought me to this forum in the first place. (Mistaken downloads of turtle seem to have come down a fair bit since a year ago, perhaps 20% - I’d like to take a tiny bit of the credit.)

Can something be done about this? Since the package belongs to a core dev (@vsajip) I thought it would make more sense to ask here first.

2 Likes

What do you think should be done? I can’t remember what the change in 0.4.9.6 (2013) was, but it’s unlikely to have been substantive. The package was added to PyPI for use with earlier versions of Python than 2.3 (it was originally developed with Python 1.5.2).

Some of these downloads might well be via automated CI tasks - it seems unlikely that thousands of new people are coming across it and downloading it.

One option available for this would be to yank all versions of this package.

4 Likes

Perhaps it would also be possible to update the existing packages’ metadata such that it wouldn’t be installed by pip?

That’s what yanking does. (The actual package metadata can’t be updated without doing a new release, and if you did that pip would simply look for an older release with compatible metadata).

4 Likes