[Distutils] Entry points: specifying and caching

[Nick Coghlan]

On 20 October 2017 at 23:19, Donald Stufft <donald at 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.


> Of course there is the perennial entrypoints are super slow, which is
> partially the fault of pkg_resources does a bunch of import time logic, but
> also because scanning sys.path for all installed stuff is just slow.
>

Similar to the above, one of the goals of documenting the entry point file
format is to permit libraries to compete in the development of effective
entrypoint metadata caching strategies without needing to bless any
particular one a priori, and without trying to manage experimental cache
designs across the huge pkg_resources install base.


> They’re also somewhat fragile since they rely on the packaging metadata
> system at runtime, and a number of tools exclude that information (often
> times things that deploy stuff as a tarball/zipfile) which causes regular
> issues to be opened up for these projects when they get used in those
> environments.
>

This is true, and one of the main pragmatic benefits of adopting one of the
purely import based plugin management systems. However, this problem will
impact all packaging metadata based plugin management solutions, regardless
of whether they use an existing file format or a new one.


> Those are the ones I remember because they come up regularly (and people
> regularly come to me with issues with any project related to packaging in
> any way even for non packaging related features in those projects). I’m
> pretty sure there were more of them that I’ve encountered and seen projects
> encounter, but I can’t remember them to be sure.
>
> I’m more familiar with why console_scripts entry point is not great and
> why we should stop using it since I regularly try to re-read all of pip’s
> issues and a lot of it’s issues are documented there.
>

I'm sympathetic to that, but I think even in that case, clearly documenting
the format as an interoperability specification will help tease out which
of those are due to the file format itself, and which are due to
setuptools.setup specifically.

Cheers,
Nick.

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