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?
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig