[Distutils] Re: [ANN] pkgdata

[Thomas Heller]

"Phillip J. Eby" <pje at telecommunity.com> writes:

> At 01:28 PM 3/25/04 -0500, Bob Ippolito wrote:
>
>>On Mar 25, 2004, at 11:28 AM, Phillip J. Eby wrote:
>>
>>>At 11:11 AM 3/25/04 -0500, Bob Ippolito wrote:
>>>> As per the BOF last night, here is the pkgdata module that I
>>>> mentioned.  Currently the only project using it is pygame.  The
>>>> "sys.datapath" mechanism that I talked about *could actually be
>>>> implemented* on top of this system, supposing an appropriate
>>>> adapter was written to support it!  Remember:  pkgdata is *just a
>>>> hook*.  It doesn't do anything other give the eventual option of
>>>> doing something smarter than
>>>> os.path.join(os.path.basedir(__file__), data).  When you figure
>>>> out what something smarter is, or you change your mind about what
>>>> the smarter solution is (inside of an app bundle vs. system wide
>>>> install, etc.), you don't have to refactor any of the code that
>>>> uses pkgdata.
>>>
>>>Do you plan to support the PEP 302 'get_data()' facility?
>>
>> Probably not, I don't think anyone ever implemented it, and it seems
>> more complicated than it needs to be.  If someone really does use
>> it, and thinks it should be implemented, please speak up.
>
> Perhaps I was unclear.  What I meant was closer to, "why not expose
> this functionality as methods on a __loader__ attribute of the module,
> and update PEP 302 if needed?"
>
> I'd love there to be a standard facility in Python for doing this, and
> have it be supported for import-from-zip, py2exe, and all the other
> possible routes to importing a module.  As far as I'm aware, PEP 302
> is the only PEP that even vaguely touches on this, so it seems to make
> sense to me to update it.

I understand what you mean, and had exactly the same idea.
I don't yet understand the code in Bob's package, probably because I
never looked at PEAK any more than 5 or 10 minutes.

What I understand (and that may be misunderstanding) is that it's a more
or less abstract api to implement this functionality, and extend it
later.

I had a probably related idea, to implement a function like 'is_frozen'
or so, which would return whether a script is executed as standard
python script, or run frozen in an executable (py2exe, Installer,
freeze, cx_freeze).  This function should hide the exact details how
this is determined, and be universally available.  This way modules
needing to know this (for example the COM registration code in
win32all^H^H^H^H^H^H^H^Hpywin32) could use this function to customize
its behaviour, with relying on internal details of py2exe or Installer.

> As you probably know, PEAK has 'config.fileNearModule()' to do this,
> but it doesn't have any mechanisms for dealing with non-file imports.
> I intend to try to implement the PEP 302 route once I get around to
> needing it.  (Although, in all honesty I'm unlikely to embrace zipfile
> imports until there's a way to use C extensions in them, at which
> point it becomes a cool way to do simple binary installs of large
> packages.)

py2exe creates a pure Python loader for each extension module, which
then dynamically loads it from the file system, without the need for the
directory of the .pyds to be in sys.path.  I don't think there is
another way to load dlls on windows (except when you unpack them from
the archive into the file system, and remove them later again - which I
consider extremly ugly).

Thomas