[Distutils] pkg_resources: import string

[Phillip J. Eby]

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.