[Distutils] Entry points: specifying and caching

[Nick Coghlan]

On 20 October 2017 at 23:42, Donald Stufft <donald at stufft.io> wrote:

> On Oct 20, 2017, at 9:35 AM, Nick Coghlan <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).

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171021/dff07201/attachment.html>