[Distutils] Entry points: specifying and caching

Donald Stufft donald at stufft.io
Fri Oct 20 09:19:37 EDT 2017


On Oct 20, 2017, at 8:41 AM, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> 
> On Fri, Oct 20, 2017, at 01:36 PM, Donald Stufft wrote:
>> Entry points have a lot of problems and I know of multiple systems that have either moved away from them, had to hack around how bad they are, have refused to implement them because of previous pain felt by them, are looking for ways to eliminate them, or which just regret ever supporting them.
> 
> The fate of the PR notwithstanding, I'd be interested in hearing more about what problems projects have experienced with entry points, if you have time to describe some examples. We're looking at using them in more places than we already do, so it would be useful to hear about drawbacks we might not have thought about, and about what other options projects have moved to.
> 

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).

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.

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.

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.



More information about the Distutils-SIG mailing list