On 22 Jul 2013 13:26, "PJ Eby" <pje@telecommunity.com> wrote:
On Sun, Jul 21, 2013 at 6:44 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 22 Jul 2013 01:46, "PJ Eby" <pje@telecommunity.com> wrote:
Now that I'm thinking about it some more, one of the motivating use cases for extras in entry points was startup performance in plugin-heavy GUI applications like Chandler. The use of extras allows for late-loading of additions to sys.path. IOW, it's intended more for a situation where not only are the entry points imported late, but you also want as few plugins as possible on sys.path to start with, in order to have fast startup.
I'm working with Eric Snow on a scheme that I hope will allow module-specific path entries that aren't processed at interpreter
startup
and never get added to sys.path at all (even if you import the module). Assuming we can get it to work the way I hope (which is still a "maybe" at this point in time), it should then be possible to backport it to earlier versions as a metaimporter.
I haven't had a chance to look at that proposal at more than surface depth, but my immediate concern with it is that it seems to be at the wrong level of abstraction for the packaging system, i.e., just because you can import a module, doesn't mean you can get at its project metadata (e.g., how would you find its exports, or even know what distribution it belonged to?).
(Also, I don't actually see how it would be useful or relevant to the use case we're talking about; it seems maybe orthogonal at best.)
The file format involved in that proposal was deliberately designed so you could also use it to look for PEP 376 dist-info directories. However, you're right, I forgot about the distribution-name-may-not-equal-package-name problem, so that aspect is completely broken in the current proto-PEP :( Cheers, Nick.
OK, so as Daniel suggested, it's more like an export/entry-point
specific
"requires" field, but limited to the extras of the current distribution.
Correct: at the time, it seemed a lot simpler to me than supporting arbitrary requirements, and allows for more DRY, since entry points might share some requirements.