[Distutils] Entry points: specifying and caching

[Wes Turner]

On Saturday, October 21, 2017, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 20 October 2017 at 23:42, Donald Stufft <donald at stufft.io
> <javascript:_e(%7B%7D,'cvml','donald at stufft.io');>> wrote:
>
>> On Oct 20, 2017, at 9:35 AM, Nick Coghlan <ncoghlan at gmail.com
>> <javascript:_e(%7B%7D,'cvml','ncoghlan at 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   |   ncoghlan at gmail.com
> <javascript:_e(%7B%7D,'cvml','ncoghlan at gmail.com');>   |   Brisbane,
> Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171021/948b2c83/attachment.html>