Hm, what would happen in the event that two conflicting names exist? We didn't always enforce this and did not retro-actively "clean up" so it could happen?

I think in the pre-existing implementation papers over that because the "exists" clause will end up a boolean through the "scalar" clause, where as after I think you'll get a list of Project objects.

doesn't scalar return the first result?

I recall it doing so if one and only one exists, otherwise a multiple results exception.

Would you mind adding a test to validate the behavior if two preexisting conflicting names exist?

uh yeah, I was looking at the wrong docs. Good catch! Fixed by replacing scalar() with first(), and added a test for it.

I know we get requests to do this often, but I don't generally think there's a ton of value in providing the conflicting project name here for two reasons:

1. we're only providing one conflicting name, but there could be multiple;
2. by providing a conflicting name, there's not a lot the user can do with it besides track down the owner, try to contact them directly, and get them to delete their project, which I think is less than ideal.

I'd rather have users submit support requests to acquire the project name and let us release names when appropriate so both projects can continue to exist.

For 1, we could return a list of project names if that was the case.

For 2, I think that only makes sense if the conflicting project is abandoned, in which case yes, the user could try to contact the owner to get them to delete it.
But for active projects, it's useful for the user to know which project is conflicting: if it's an active or well-known package they probably won't want to take over it.

Knowing exactly which project is too similar in name allows the user to make the decision if they should go forward or not with trying to get that name, whereas otherwise they are forced to go through PyPI support without knowing which package they are trying to get deleted/released.

This case is when a user explicitly wants a different name than the conflicting name though, so the ideal situation would be that they could go forward with publishing under the original name, and not have to take over or delete a slightly different name in order to use the original name.

Adding multiple conflicting names to the error message would just exacerbate this I think: what would we expect the user to do with that information? The better outcome would be that regardless of what the conflicting names(s) are, they are able to request the original name.

For 1, we could return a list of project names if that was the case.

I think this could work, although in principle the list of conflicting names is unbounded (or could become unbounded with a future restriction on similarity).

I think @di's point with contact is that maintainers will find it annoying/frustrating to have deletion requests directed at them first, especially since there's typically no (strong) public signal that a project is actually abandoned. There's also a possibility that less-experienced users think that the project itself is imposing the restriction, which will lead to reports from those users that the projects can't actually do anything about (e.g. "pip is preventing me from uploading p1p to PyPI").

so the ideal situation would be that they could go forward with publishing under the original name, and not have to take over or delete

Ah, I wasn't aware that this could be done (allowing a new project that has a too-similar name as an existing one). I see you mentioned at the end of your original comment, I just didn't register it 🤦

I see your point. I still think knowing the name might be useful in some cases (for example, if I'm trying to create p1p, and I see that it conflicts with pip, I will just find a different name rather than ask the PyPI admins about it).

But I'm guessing this is rare, and not worth modifying the error message for.
WDYT about the rest of the PR? Should I remove the changes related to the too-similar error, and leave the rest as-is?. Or should we go with a different implementation, since we're only adding extra information to the "already exists" error?

WDYT about the rest of the PR? Should I remove the changes related to the too-similar error, and leave the rest as-is?. Or should we go with a different implementation, since we're only adding extra information to the "already exists" error?

IMO we can leave it in, and just drop it from the public facing message for now 🙂.

I see your point. I still think knowing the name might be useful in some cases (for example, if I'm trying to create p1p, and I see that it conflicts with pip, I will just find a different name rather than ask the PyPI admins about it).

Generally we want the user to be able to use their first preference rather than hunt around for a less ideal name, though!

IMO we can leave it in, and just drop it from the public facing message for now 🙂.

Seems fine to me.

Done, removed the name from the error message

I will say I've had a lot of luck asking people to delete dormant packages so I can use the name, pretty quickly.

But I've had very little luck with support requests, e.g.they take ages and don't always work. E.g. we've reported copyright legal violations and had security concerns and had no response after months.

Having the package name would be very useful in real world scenarios.

E.g. we've reported copyright legal violations and had security concerns and had no response after months.

@samuelcolvin For security-concern requests going without response, can you elaborate where these were reported? I monitor the security inbox closely and investigate violations pretty quickly.