[Distutils] Q about best practices now (or near future)

[PJ Eby]

On Sun, Jul 21, 2013 at 6:44 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> On 22 Jul 2013 01:46, "PJ Eby" <pje at 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.)


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