[Distutils] Accessing package data files in wheels

[Paul Moore]

On 29 June 2015 at 07:56, Paul Sokolovsky <pmiscml at gmail.com> wrote:
>> If you want to avoid a dependency on pkg_resources, you can use
>> pkgutil.get_data (from the stdlib). It doesn't have as many features
>> as pkg_resources, but it does the job in straightforward cases.
>
> Which makes everyone in the audience wonder: how it happens that it's
> 2015, Python is at 3.5, but pkgutil.get_data() is in stdlib, while
> pkg_resources.resource_stream() isn't? An implementation of
> pkgutil.get_data() would be based on pkg_resources.resource_stream(),
> or would contain just the same code as the latter, so it could easily
> be exposed, and yet it isn't.

In addition to Nick's response, which are the main reasons, there is
also a more fundamental issue behind this.

The PEP 302 definition of a loader only provides a get_data method,
which corresponds directly to pkgutil.get_data. Any additional
features provided by pkg_resources are not supported directly by the
loader protocol, and so could not be guaranteed to be present for an
arbitrary loader. pkg_resources provides the extended features (I
believe) by special-casing filesystem and zip loaders, and providing
an extension mechanism for other loaders to participate in the
functionality, but that extension mechanism is not in the stdlib
either.

So adding more resource loading features means extending the PEP 302
protocols, etc. That's the work that no-one is currently doing that
blocks the process.

Having said all this, PEP 302 is pretty old now, and importlib makes
all of this *much* easier, so (as long as you're only targeting recent
Python versions, which stdlib support would be) it's a lot simpler to
do this now than it was when we wrote PEP 302. And of course, in
practical terms filesystem and zip loaders are the only significant
ones that exist anyway...

Paul