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.