On Saturday, October 21, 2017, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 20 October 2017 at 23:42, Donald Stufft <don...@stufft.io > <javascript:_e(%7B%7D,'cvml','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: >> 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. >> > > The semantics of conflict resolution across different projects is a > concern that mainly affects app developers a large established plugin base, > and even with pkg_resources the question of whether or not multiple > projects re-using the same entrypoint name is a problem depends on how the > application uses that information. > > With console_scripts and gui_scripts, name conflicts can definitely be a > problem, since different projects will end up fighting over the same > filename for their executable script wrapper. > > For other use cases (like some of the ones Doug described for stevedore), > it's less of a concern, because the names never get collapsed into a single > flat namespace the way script wrappers do. > > Cheers, > Nick. > > P.S. Thanks for your comments on the PR - they're helping to make sure we > accurately capture the status quo. I'm also going to file an issue on the > setuptools issue tracker to make sure Jason is aware of what we're doing, > and get his explicit OK with the idea of making the format a PyPA > interoperability specification (if he isn't, we'll demote Thomas's document > to being a guide for tool developers aiming for pkg_resources > interoperability). > What are the URIs for this PR and issue? > > -- > Nick Coghlan | ncogh...@gmail.com > <javascript:_e(%7B%7D,'cvml','ncogh...@gmail.com');> | Brisbane, > Australia >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig