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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
