[eesmith]

I had a package which I didn't publish on PyPI, just my web site as a "if you break it, you get to keep the pieces" sort of thing. I didn't even have a PyPI account.

Someone else added it to PyPI without telling me. And people started using it from PyPI.

I started getting messages about it, like PyPI developers asking maintainers to upgrade package metadata to include if it supported Python 3. That's when I realized it was on PyPI in the first place.

I had to contact the original uploaded to get access to the account.

One user even emailed me a question and said I had an obligation to support it, since I put it on PyPI.

Damned if you do, damned if you don't.

[staticassertion]

I don't really see the problem. You put the code online and someone published it to PyPI. That you got what effectively amounts to spam emails because of that doesn't seem pertinent. Just block the emails. Unfortunately, putting out public communication addresses like emails does indeed invite all kinds of unwanted, unsolicited messaging.

Why not just ignore that like any other spam?

[eesmith]

My point was that a personal project that you have on github could still be put onto PyPI by someone else, without you knowing. Even if you actively want to avoid PyPI.

What you want to do about it is a different topic.

Unlike most spam, I can't figure out how to select interesting email about my projects that I want to answer, from emails I don't want to read at all because they make my blood boil, like those asserting that because the project is on PyPI I'm obligated to help them.

It's rather moot now as I haven't gotten emails about it for 8-10 years.

Huh. As a supply-chain issue, is it important to PyPI that the person in charge of the PyPI entry be affiliated with the project, and share reputational risks should the PyPI packager add malware?

That seems like an interesting vector. Find a potentially useful Python package which isn't distributed via PyPI, add an entry using a new account which looks like it's part of the project, add malware, and upload.

[mariuolo]

> I had to contact the original uploaded to get access to the account.

That's your mistake there. Others would have left it alone or added a note somewhere.

But that begs the question: why doesn't pypi verify that uploader and developer coincide?

[eesmith]

> Others would have left it alone or added a note somewhere.

I doubt I'm unique in this regard.

> why doesn't pypi verify that uploader and developer coincide?

How would that verification process work?

I have failed to find a PyPI requirement that they coincide.

It appears that if you have a public repo with a FOSS project but no PyPI entry then anyone is free to use your repo to create a PyPI entry. It's not quite namesquatting given that it's (at least at the start) the same code base.

I'm not sure if PyPI even allows a name transfer to you, if I read https://peps.python.org/pep-0541/#name-conflict-resolution-f... correctly:

] None of the following qualify for package name ownership transfer ... User A owns a project X outside the Package Index. User B creates a package under the name X on the Index. After some time, User A wants to publish project X on the Index but realizes name is taken.

EDIT: Someone who avoids submitting to PyPI because of philosophical objections to the PSF Code of Conduct appears to have no recourse should this happen, as the resolution process requires following the PSF Code of Conduct.