On Saturday, October 21, 2017, Nick Coghlan firstname.lastname@example.org wrote:
I think it makes it *worse*, because now the behavior isn’t just a entrypoints weirdness, but now it changes based on which runtime library you use (which isn’t something that end users are likely to have much insight into) and it represents a footgun that package authors are unlikely to be aware of. If mycoolentrypointslib comes out that is faster, but changes some subtle behavior like this it’ll break people, but that is unlikely going to be an effect that people expect to happen just because they switched between two things both implementing the same standard.
So effectively this means that not only is the fact you’re using entrypoints part of your API, but now which entry point library you’re using at runtime is now also part of your API.
The semantics of conflict resolution across different projects is a concern that mainly affects app developers a large established plugin base, and even with pkg_resources the question of whether or not multiple projects re-using the same entrypoint name is a problem depends on how the application uses that information.
With console_scripts and gui_scripts, name conflicts can definitely be a problem, since different projects will end up fighting over the same filename for their executable script wrapper.
For other use cases (like some of the ones Doug described for stevedore), it's less of a concern, because the names never get collapsed into a single flat namespace the way script wrappers do.
P.S. Thanks for your comments on the PR - they're helping to make sure we accurately capture the status quo. I'm also going to file an issue on the setuptools issue tracker to make sure Jason is aware of what we're doing, and get his explicit OK with the idea of making the format a PyPA interoperability specification (if he isn't, we'll demote Thomas's document to being a guide for tool developers aiming for pkg_resources interoperability).
What are the URIs for this PR and issue?