On 22 Jul 2013 13:26, "PJ Eby" <p...@telecommunity.com> wrote: > > On Sun, Jul 21, 2013 at 6:44 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > > > On 22 Jul 2013 01:46, "PJ Eby" <p...@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.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
