[Distutils] [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Paul Moore]

On 19/03/2008, Phillip J. Eby <pje at telecommunity.com> wrote:
> It's so that you can get loaders for modules that aren't imported yet
>  -- and your code would need to handle this case too.

Well, technically, it need not, as I don't *need* to implement the
exact functionality that pkg_resources does. My (personal) goal is to
standardise the functionality, not to cater for every possible use
case.

>  (You could handle it by actually going ahead and importing the module, as
>  pkg_resources does, but there are other tools using pkgutil to e.g.
>  inspect as-yet-unimported modules.)

I'm not sure what you mean by that. There are no tools using
pkgutil.resource_stream, as it doesn't exist yet. So whether it
imports the module or not cannot be relevant (although it should be
documented).

> You don't really need to, because even though they're technically
>  "undocumented", the intent was for them to be published APIs (apart
>  from simplegeneric, which is an implementation detail).  The docs
>  just never got copied to the official docs.

If it's just a matter of copying documentation from the PkgResources
page, that's no issue. However, only get_importer is documented on the
PkgResources page.

On reviewing the pkg_resources APIs, I only see the following that
look worth porting to pkgutil:

    * resource_exists(package, resource_name)
    * resource_stream(package, resource_name)
    * resource_string(package, resource_name)
    * resource_isdir(package, resource_name)
    * resource_listdir(package, resource_name)

For all of these, the first argument would be restricted to a
package/module name. The option of specifying a "requirement" is not
suitable. Also, automatic extraction and resource_filename is far
beyond what I see as sensible in the stdlib.

Hmm, these go way beyond the simple (and optional) loader.get_data
interface from PEP 302. And yet the pkg_resources machinery is far
more complex than I'd want to see in the stdlib. Maybe I'll just
reinvent the wheel and see how far I get :-)

Paul.