[Distutils] API for finding plugins

[Ian Bicking]

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.

> OTOH, as long as the interfaces are well-defined, nothing stops you from 
> creating logging "middleware" for debugging purposes, I suppose.  I just 
> don't want to embed that stuff in core code, if for no other reason than 
> that the logging module is a PITA.

I don't really care about the logging module.  If you could just pass in 
a callable where things are written to (defaut to None which does no 
writing), that would be good enoguh -- no log levels or anything fancy 
like that.


>> OK, that's probably all I mean.  I just don't want someone to get 
>> "/images/", and then look inside their for "plus.gif", and get a not 
>> found error because it looks inside the directory named /images/ that 
>> was found which only contains a subset of files.
> 
> 
> Oh, no...  I'm assuming that the attribute namespaces are entirely 
> flat.  If you want directories or some other kind of hierarchy you would 
> need to simulate them using 'directory' attributes or something like 
> that.  I'm assuming also that an individual resource can have more than 
> one value for an attribute, so that a single resource could be e.g. 
> registered for both 'en' and 'en-US' locales.

OK, that's fine then; I want opaque names (not hierarchical names) anyway.

>>   Unless there was some kind of wildcard that a resource could 
>> provide.  Like providing "my_page" for any project.  I don't expect 
>> there to be such a wildcard...?
> 
> 
> I don't either.  Multiple values for an attribute, yes.  Wildcard 
> attributes, not really, at least not as part of the system itself.   
> Wildcards can be simulated by either omitting a value from a search, or 
> having an explicit wildcard value that's always searched last in a list.

Yeah, I figured ad hoc conventions for wildcards would be sufficient.  A 
provider could, potentially, say that every resource it provides also 
satisfies '*' for some attribute, and you could query with '*' at the 
end of the list.

I assume when a criteria is omited entirely then any resource will match 
that criteria.  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.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org