At 11:27 AM 8/2/2005 -0500, Ian Bicking wrote:
Phillip J. Eby wrote:
At 05:09 PM 8/1/2005 -0500, Ian Bicking wrote:
I was thinking some more about WSGI configuration, and much configuration involves some "import a string" routing, that looks like importstring("os.path:sep") or somesuch. But we implement it slightly differently. And maybe there could be a PEP and whatnot, but I don't even know what module that would go into, and it would just have to be backported for a long time anyway... but then it seemed like it would fit nicely into pkg_resources, and just about anywhere I want to import strings I expect pkg_resources to be around as well.
from pkg_resources import EntryPoint def import_string(s): return EntryPoint.parse("x="+s).load(False)
OK... the error messages will be a little funny due to the appropriation of the functionality from a different feature.
Huh? They're just ImportErrors, and they don't mention EntryPoint in any way. Unless you mean syntax errors, in which case you can always trap ValueError and reraise it.
It would be nice if this was a separate function. Also, what about evaluating the text after ':' in the scope of the module, instead of using getattr?
Um, no. If you want expressions, write code. :)
Relatedly, in most places where I want to use this, I now also want to use a entry point spec. But I don't know what entry point specs should look like. So maybe even better would be a combination of the two. This might look like:
def import_string(spec, group=None): if group is not None and ' ' in spec: dist, name = spec.split(None, 1) return load_entry_point(dist, group, name) return EntryPoint.parse('x='+spec).load(False)
This uses a convention of "PackageName entry_point_name", with the space distinguishing this from other imports. But I think a space is a rather vague way to make the distinction... maybe "PackageName[entry_point_name]"? Then if [ comes before any : it's a entry point, otherwise it's an importable string.
If that sounds good I can submit a patch that does more thorough error checking, and separates the importing from EntryPoint.
I don't like this. It's way too vague a concept that doesn't fit into pkg_resources architecture yet. I don't mind making a nice import-string function, but this package/entry-point thing is getting too... blurry. I need a better idea of how this fits into things overall, as I can more clearly see use cases for: * Import a list of all entry points matching some description * Import the first entry point matching something * Create a dictionary of lists of imported entry points etc. Whereas for the "import a specific entry point from a specific place", I see only application-specific needs. For example, to get a wsgi.app_factories or wsgi.middleware_factories entry, where the group is implicit and not part of the syntax. This is why I have difficulty seeing a syntax for loading entry points as being part of pkg_resources. I mean, it's hard to get much simpler at the API level than what pkg_resources has for entry points right now, and the API supports all these use cases and more. Adding syntax for your specific application/framework doesn't make sense to me because I don't see how anybody else is going to use it. Also, the syntax you propose seems broken to me because it doesn't support versioning, and because the brackets can be confused with "extras" syntax. If you want to use it in your own framework, I certainly can't stop you, but I don't want to mix something that's so close to -- yet completely different from -- the basic requirement syntax into the general API.