Excerpts from Wes Turner's message of 2017-10-20 10:41:02 -0400:
On Friday, October 20, 2017, Donald Stufft <donald@stufft.io> wrote:
On Oct 20, 2017, at 9:35 AM, Nick Coghlan <ncoghlan@gmail.com <javascript:_e(%7B%7D,'cvml','ncoghlan@gmail.com');>> wrote:
On 20 October 2017 at 23:19, Donald Stufft <donald@stufft.io <javascript:_e(%7B%7D,'cvml','donald@stufft.io');>> wrote:
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).
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.
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.
When should the check for duplicate entry points occur?
- At on_install() time (+1) - At runtime
Is a sys.path-like OrderedDict preemptive strategy preferable or just as dangerous as importlib?
Having "duplicate" entry points is not necessarily an error. It's a different usage pattern. The semantics of dropping a named plugin into a namespace are defined by the application and plugin-point. Please do not build assumptions about uniqueness into the underlying implementation. The stevedore library wraps up pkg_resources with several such patterns. For example, it supports "give me all of the plugins in a namespace" (find all the extensions to your app), "give me all of the plugins named $name in a namespace" (find the hooks for a specific event defined by the app), and "give me *the* plugin named $name in a namespace" (load a driver for talking to a backend). https://docs.openstack.org/stevedore/latest/reference/index.html Doug