On 20 October 2017 at 23:42, Donald Stufft <donald@stufft.io> wrote:

On Oct 20, 2017, at 9:35 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
The interoperability spec is going to state that conflict resolution when the same name within a group is declared by multiple packages is the responsibility of the group consumer, so documenting the format should actually improve this situation, since it allows for the development of competing conflict resolution strategies in different runtime libraries.
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.

Cheers,

Nick.

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).

Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia