<br><br>On Friday, October 20, 2017, Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Oct 20, 2017, at 9:35 AM, Nick Coghlan <<a href="javascript:_e(%7B%7D,'cvml','ncoghlan@gmail.com');" target="_blank">ncoghlan@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 20 October 2017 at 23:19, Donald Stufft <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','donald@stufft.io');" target="_blank">donald@stufft.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
</span>One that I was helping someone debug just the other day is that they’re super non-debuggable and the behavior when you have two things providing the same entry point is basically ???? (If I remember correctly, the behavior is that the first thing found is the one that “wins”, which means the ordering of sys.path and the names of the projects supply it is what determines it). This got exposed to the end user that they installed something that they thought was going to add support for something, but which silently did nothing because two different project happened to pick the same name for their entry point (not the group, it was two things providing plugins for the same system).<br></blockquote><div><br></div><div>While I agree with this, I think that's a combination of pkg_resources itself being hard to debug in general, and the fact that pkg_resources doesn't clearly define the semantics of how it resolves name conflicts within an entry point group - as far as I know, it's largely an accident of implementation.</div><div><br></div><div>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.<br></div></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>When should the check for duplicate entry points occur?</div><div><br></div><div>- At on_install() time (+1)</div><div>- At runtime</div><div><br></div><div>Is a sys.path-like OrderedDict preemptive strategy preferable or just as dangerous as importlib?<br></div>