[Distutils] API for finding plugins
Phillip J. Eby
pje at telecommunity.com
Wed Feb 8 19:46:38 CET 2006
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
> 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.
More information about the Distutils-SIG