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