[Distutils] Re: [ANN] pkgdata
theller at python.net
Thu Mar 25 14:58:27 EST 2004
"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
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
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).
More information about the Distutils-SIG