[Distutils] API for finding plugins

[Phillip J. Eby]

At 12:10 PM 2/8/2006 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>>   Also, logging of some sort should go in early, I think, as it should 
>>> be expected that resource resolution will have to be debugged, and the 
>>> only way I imagine it being debuggable is through log messages.
>>
>>You lost me on that.  I'm having trouble seeing what you'll be able to 
>>(or need to) debug that way.  The most likely problems are that you 
>>misspell something (in which case there'll be no matches at all) or 
>>you're missing a provider (in which case studying the list of the 
>>providers will give you the answer).  In each case, inspecting the 
>>current state of the system seems sufficient.
>
>I disagree strongly here.  There are two cases I see that need to be 
>debugged: you get the wrong resource, and you get no resource at all. Both 
>of these can be very confusing.  Certainly I regularly find 404s to be 
>confounding.  I don't want to have to put print statements in other 
>people's resource-finding code in order to figure out what's going 
>wrong.  I'm regularly putting print statements in pkg_resources to figure 
>out what's going wrong.
>
>Also, "inspecting the current state of the system" isn't really 
>feasible.  The current state is in memory, often in opaque objects.  And 
>people who are debugging this are often going to be non-programmers, who 
>don't have any means or understanding of the internal state of the system.

Actually, I'm assuming that the system would provide sufficient state info 
to allow you to create a viewer or query tool that would let you see and 
search through all available resources, or to dump them to a tab-delimited 
file that you can massage in Excel or Access or some such thing to see 
what's going on.  It is, after all, just a database, so a few filters and 
sorts should suffice to isolate what is or isn't there.

Mostly, I think debugging effectively needs to take place on the *input* 
end.  That is, on the files that are going into your egg to begin 
with.  Resource finders should display warnings about the resources they 
didn't or couldn't index.

On the other hand, this highlights the fact that rerunning egg_info every 
time you add templates to a project would probably be a PITA in itself, 
meaning that what you probably really want is for resource finders to be 
something that runs at lookup time, not egg building time.  What sucks 
about that is, you'll have to import all the finders at run time, unless 
you have some kind of project filter.  Bleah.

By project filter, I mean some way for a project to indicate what other 
projects it offers resources for.  That way, at runtime you could skip 
loading finders for eggs that don't relate to the project you're looking 
up.  This is about the only kind of hint I can think of that can reasonably 
be hardcoded to prevent unnecessary dynamic lookups at runtime.

The whole thing seems a little messy, since you could have both runtime 
resource finding and build-time resource finding, which sounds like it's 
just asking for trouble.  It might be better to just use runtime searching 
only...  in which case we end up back at needing logging, unless there's a 
prescan process involved.  Ah well.  In any case, we have to support 
runtime searches for development uses.


>I assume when a criteria is omited entirely then any resource will match 
>that criteria.

Yeah.


>   I suppose there is possibly a use case for "satisfies some related 
> criteria", even if you don't have any specific criteria in mind.  E.g., 
> "satisfies some template_language=anything", even if you don't care 
> template language in particular.  But you don't want to match CSS files 
> if you are looking for a template.  OTOH, that could be done with 
> "resource_type=['template']" or something like that.

Yeah, I really want to keep the data model ridiculously simple; you 
shouldn't have to implement a "real" database for this stuff.