Excerpts from Wes Turner's message of 2017-10-20 10:41:02 -0400: > On Friday, October 20, 2017, Donald Stufft <don...@stufft.io> wrote: > > > > > > > On Oct 20, 2017, at 9:35 AM, Nick Coghlan <ncogh...@gmail.com > > <javascript:_e(%7B%7D,'cvml','ncogh...@gmail.com');>> wrote: > > > > On 20 October 2017 at 23:19, Donald Stufft <don...@stufft.io > > <javascript:_e(%7B%7D,'cvml','don...@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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
