Jeremy Kloth <[EMAIL PROTECTED]> wrote:
>> In fact, what is the reason for a frozen application to ever need
>> pkg_resources?
>
> To find package data files.
As documented by the manual, PyInstaller does not yet support .egg files (or
zipimports for that matter), nor any other setuptools-related features. With
"setuptools-realted feature", I mean every new complex and nifty feature that
was introduced into Python because of (or thinking of) setuptools. I had heard
that pkg_resources can be used to access data files in a way that makes the
client agnostic of how the package is distributed and where it is installed,
but I have never used it directly, nor I have any deeper knowledge. In fact,
setuptools documentation appears a little sparse at best, and mostly a large
reference (which is the less interesting part when you want to learn something
new).
> For data files, it uses the __loader__ module attribute.
Never heard of this before now. I see PEP 302 mention this, but I can't see
offhand how this is related to data files. I will have to look into
pkg_resources documentation (hoping it's improved since last year). If you have
a pointer, it'd be appreciated.
> If PyInstaller does not support PEP 302, it is seriously broken as the
> other freezing applications (py2exe, py2app and cx_Freeze) support
> this just fine.
It is "seriously" broken for applications relying on modules distributed in a
non-standard way (setuptools won't *even* be in Python 2.5), or at least using
a third-party module used to access data files (pkg_resources) which relies on
a PEP which is not yet even officially "Accepted" but just implemented as draft
for testing purposes.
This doesn't mean I do not want to fix it: I would be interested in
understanding better of all this stuff and giving PyInstaller a better
compatibility, but I rarely consider a good usage of time doing too much work
to support non-standard extensions. Patches are welcome, though.
> For distributions, however it will scan sys.path for .egg[info]
> directories and/or files. Currently no freezing applications support
> this out of the box, but can be tweaked (at least py2exe and
> cx_Freeze) to include those files so that pkg_resources can find
> distributions as well. This approach does require additions to user
> code as well.
I have no clue what is a "distribution" for you. It is not a standard Python
term AFAICT, unless you refer to something like "CPython Windows distribution",
which you probably do not.
> It seems to me that PyInstaller is quite behind the curve when
> compared to the other freezing applications.
Depends on your point of view. You seem to be interested in "advanced" and
experimental work of import hooks, setuptools, .eggs and whatnot. Most of this
stuff is not even part of a standard Python distribution, it is just
third-party stuff at this time. I see it's becoming popular, but I don't think
this makes PyInstaller "behind the curve", at least in the industry. I never
ever had to use setuptools in my life until now, and I am a full time Python
programmer. The couple of stuff I tried which use setuptools worked with
PyInstaller quite well (eg. SQLObject).
You are the very first one mentioning me pkg_resources; setuptoosl is not still
widely estabilished in the Python community (or in the Python industry, let me
say). OTOH, just to do an example, I have received many bugreports and tickets
about advanced usages of Python with Windows COM interfaces (which, I'm told,
PyInstaller support wayyyy better than the other freezing programs). So, if I
were to follow what the PyInstaller community prompts me to do and allocate my
spare time to fix tickets, I would be forced to give priority to COM issues,
since many more people reported them.
Moreover, PyInstaller has unique features which are *very* important for me:
for instance it does not require hundreds of Wiki pages explaining how to tweak
external modules or what to manually write in your setup.py file to make them
work, since it can patch them on-the-fly, automatically (eg. adding hidden
imports) through the hooks mechanism. Sometimes it even requires real-time
hooks (which monkey-patch the module when imported): I dare you find a freezing
application which does support out-of-the-box an unpatched version of PyOpenGL,
or PIL (as recently fixed after it changed again); "out-of-the-box" means
without having to write a *single* line of code. Another feature which I value
most is that PyInstaller produce single-file executables on Windows which do
not rely on undefined and undocumented Windows behaviours to boot (see the
in-memory DLL loader of py2exe): I would NEVER ship a commercial product with
such a bootloader, and I know many other people who agree with this.
> On the flip side, it is
> the only freezing application that supports Python versions prior to
> 2.3.
It is also the freezing application that is multiplatform. It is also packed
with many small little unique features which become apparent when you start
using it for real-world non-trivial jobs (for instance, its programmable syntax
for spec files), so I encourage you to go a little further than
cross-list-checking bleeding-edge non-standard import features and give it a
real spin.
> I guess that that is the whole issue as PEP 302 was first
> implemented in 2.3 so it would cause a fork in the code to support
> both methods. Which may be why the other applications dropped
> support for the earlier versions.
As I said, given that you're the first one to *ever* mention setuptools-related
breakage to me, I'd be a fool if I dropped pre-2.3 support for just this
bugreport, especially since I know many users which build applications with
older versions of Python (2.0+ at least... I don't know anyone using
PyInstaller with 1.5, and I would in fact be thrilled to drop 1.x support since
it's a PITA).
This does not mean that I am not going to fix PyInstaller imports. It just
means that I need a better overview of what is exactly broken and how wide is
the breakage, before using my little spare time on it. I would appreciate more
constructive feedback, in fact. If you could open a ticket with a specific bug,
a specific reference to whatever advanced PEP302 is missing ("implement PEP302"
is a little too generic), I'd be glad to have a look. There are other serious
bugs in PyInstaller import machinery (see Ticket #1 for instance) which I would
like to squash.
Giovanni Bajo
_______________________________________________
PyInstaller mailing list
[email protected]
http://lists.hpcf.upr.edu/mailman/listinfo/pyinstaller
