[Distutils] Accessing package data files in wheels

[Nick Coghlan]

On 29 June 2015 at 16:56, Paul Sokolovsky <pmiscml at gmail.com> wrote:
> Hello,
>
> On Sun, 28 Jun 2015 13:02:40 +0100
> Paul Moore <p.f.moore at gmail.com> wrote:
>
>> On 27 June 2015 at 19:52, Justin Uang <justin.uang at gmail.com> wrote:
>> > What is the recommended way to get access to a data file in my
>> > package if I'm using a wheel? pkg_resources seems like it's mainly
>> > useful because eggs might be used in a zipped form, but for wheels,
>> > I'm guaranteed that the data will be unpacked into a directory
>> > structure right? In that case, should I just use __file__ to
>> > manually find the location of the file?
>>
>>
>> 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.

This has the same 3 part answer as a lot of "Why isn't this in the
standard library?" questions:

1. nobody has volunteered to drive the standardisation process
2. most of the folks who currently need this functionality want to
support older versions of Python, so something pip-installable is
actually more use to them than standard library support
3. the folks that *are* currently working on improving the
out-of-the-box experience are working on other aspects of that problem

(1) is the actual reason, while (2) and (3) are then a couple of the
second order factors contributing to (1)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia