Disclaimer: I personally have no use for setuptools and am actually against
some of the decisions that it uses but have bent to support users that would
like to use 4Suite in the .egg-world.
On Saturday 05 August 2006 8:04 pm, Giovanni Bajo wrote:
> 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.
That tidbit of information I had to learn by perusing the code. This is not
jut setuptools, but both py2exe and cx_Freeze use zipimports which, in turn,
use this mechanism.
> > 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.
I'll give you that PEP 302 is still an open PEP, but PEP 273 (zipimports) is
considered finished and is implemented via the methods described by PEP 302
so I believe that 302 is defacto accepted.
> 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.
I would consider zipimports very standard.
> > 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.
Perhaps I've spent to much time on the distutils-sig list, but a distribution
is something produced by distutils (or in this case, setuptools, which is a
distutils extension). The term "package" isn't used as it is too easily
confused with Python packages (directories).
> > 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).
I'm simply referring to the support of zipimports, a standard part of Python
since 2.3, over 3 years ago. Not something that I would consider
experimental. It just so happens that setuptools uses zipimports for its .egg
files.
> 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.
I agree that features/bugfixes based on the community feedback is important.
This is the reason I went to investigating py2exe, cx_Freeze and setuptools
in the first place. From my POV, supporting zipimports is the way to go
since it covers all three with the same effort. Not something I can say for
PyInstaller as this is the first I have ever heard of it.
> 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 have no personal need or use for freezing programs other than to make sure
that users of 4Suite have little to no issues in using whatever "freezer"
they choose.
> > 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.
All that I would like to see PyInstaller be able to do is simply support
zipimports as implemented by Python 2.3. If that were to happen, it would
further bring the "freezing landscape" closer to one common way of
functionality, it stead of forcing us library developers to add case after
case to support each different way of freezing. Not to mention the ability
to shared code and ideas with the other freeze projects.
--
Jeremy Kloth
http://4suite.org/
_______________________________________________
PyInstaller mailing list
[email protected]
http://lists.hpcf.upr.edu/mailman/listinfo/pyinstaller
