<br><br>On Friday, October 20, 2017, Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Wes Turner's message of 2017-10-20 10:41:02 -0400:<br>
> On Friday, October 20, 2017, Donald Stufft <<a href="javascript:;" onclick="_e(event, 'cvml', 'donald@stufft.io')">donald@stufft.io</a>> wrote:<br>
><br>
> ><br>
> ><br>
> > On Oct 20, 2017, at 9:35 AM, Nick Coghlan <<a href="javascript:;" onclick="_e(event, 'cvml', 'ncoghlan@gmail.com')">ncoghlan@gmail.com</a><br>
> > <javascript:_e(%7B%7D,'cvml','<a href="javascript:;" onclick="_e(event, 'cvml', 'ncoghlan@gmail.com')">ncoghlan@gmail.com</a><wbr>');>> wrote:<br>
> ><br>
> > On 20 October 2017 at 23:19, Donald Stufft <<a href="javascript:;" onclick="_e(event, 'cvml', 'donald@stufft.io')">donald@stufft.io</a><br>
> > <javascript:_e(%7B%7D,'cvml','<a href="javascript:;" onclick="_e(event, 'cvml', 'donald@stufft.io')">donald@stufft.io</a><wbr>');>> wrote:<br>
> ><br>
> >> One that I was helping someone debug just the other day is that they’re<br>
> >> super non-debuggable and the behavior when you have two things providing<br>
> >> the same entry point is basically ???? (If I remember correctly, the<br>
> >> behavior is that the first thing found is the one that “wins”, which means<br>
> >> the ordering of sys.path and the names of the projects supply it is what<br>
> >> determines it). This got exposed to the end user that they installed<br>
> >> something that they thought was going to add support for something, but<br>
> >> which silently did nothing because two different project happened to pick<br>
> >> the same name for their entry point (not the group, it was two things<br>
> >> providing plugins for the same system).<br>
> >><br>
> ><br>
> > While I agree with this, I think that's a combination of pkg_resources<br>
> > itself being hard to debug in general, and the fact that pkg_resources<br>
> > doesn't clearly define the semantics of how it resolves name conflicts<br>
> > within an entry point group - as far as I know, it's largely an accident of<br>
> > implementation.<br>
> ><br>
> > The interoperability spec is going to state that conflict resolution when<br>
> > the same name within a group is declared by multiple packages is the<br>
> > responsibility of the group consumer, so documenting the format should<br>
> > actually improve this situation, since it allows for the development of<br>
> > competing conflict resolution strategies in different runtime libraries.<br>
> ><br>
> ><br>
> > I think it makes it *worse*, because now the behavior isn’t just a<br>
> > entrypoints weirdness, but now it changes based on which runtime library<br>
> > you use (which isn’t something that end users are likely to have much<br>
> > insight into) and it represents a footgun that package authors are unlikely<br>
> > to be aware of. If mycoolentrypointslib comes out that is faster, but<br>
> > changes some subtle behavior like this it’ll break people, but that is<br>
> > unlikely going to be an effect that people expect to happen just because<br>
> > they switched between two things both implementing the same standard.<br>
> ><br>
> > So effectively this means that not only is the fact you’re using<br>
> > entrypoints part of your API, but now which entry point library you’re<br>
> > using at runtime is now also part of your API.<br>
> ><br>
><br>
> When should the check for duplicate entry points occur?<br>
><br>
> - At on_install() time (+1)<br>
> - At runtime<br>
><br>
> Is a sys.path-like OrderedDict preemptive strategy preferable or just as<br>
> dangerous as importlib?<br>
<br>
Having "duplicate" entry points is not necessarily an error. It's<br>
a different usage pattern.  The semantics of dropping a named plugin<br>
into a namespace are defined by the application and plugin-point.<br>
Please do not build assumptions about uniqueness into the underlying<br>
implementation.</blockquote><div><br></div><div>I think that, at least with console_scripts, we already assume uniqueness: if there's another package which provides a 'pip' console_script, for example, there's not yet an error message?</div><div><br></div><div>Would it be helpful to at least spec that iterated entrypoints are in sys.path order? And then what about entrypoints coming from the same path in sys.path: alphabetical? Whatever hash randomization does with it?</div><div><br></div><div>Whenever I feel unsure about my data model, I tend to sometimes read the OWL spec: here, the OWL spec has owl:cardinality OR owl:minCardinality OR owl:maxCardinality. Some entrypoints may have 0, only one, or n "instances"?</div><div><br></div><div>We should throw an error if a given console_script entrypoint has more than one "instance" (exceeds maxCardinality xsd:string = 1).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The stevedore library wraps up pkg_resources with several such<br>
patterns. For example, it supports "give me all of the plugins in<br>
a namespace" (find all the extensions to your app), "give me all<br>
of the plugins named $name in a namespace" (find the hooks for a<br>
specific event defined by the app), and "give me *the* plugin named<br>
$name in a namespace" (load a driver for talking to a backend).<br>
<br>
<a href="https://docs.openstack.org/stevedore/latest/reference/index.html" target="_blank">https://docs.openstack.org/<wbr>stevedore/latest/reference/<wbr>index.html</a></blockquote><div><br></div><div><a href="https://github.com/openstack/stevedore/blob/master/stevedore/extension.py">https://github.com/openstack/stevedore/blob/master/stevedore/extension.py</a><br></div><div><br></div><div><a href="https://github.com/openstack/stevedore/blob/master/stevedore/tests/test_extension.py">https://github.com/openstack/stevedore/blob/master/stevedore/tests/test_extension.py</a><br></div><div><br></div><div>These tests mention saving discovered entry points in a cache?</div>