Getting tired with py2exe
Thomas Heller
although it has interesting features (I would say).
The problem, apart from the work, is that it is good enough for me - I
can do everything that I need with it. But I assume I use far less
libaries than other Python programmers, so a lot of bugs will never bite
me.
It is also interesting that the recently introduced bundle-files option,
which allows to build single-file exes has gained a lot of interest -
although the ONLY use case (so far) I have myself for it is to implement
inproc COM servers which will compatible with Python clients (and other
Python inproc COM servers) because of the total isolation of the Python
VMs.
Is anyone interested in taking over the maintainance, documentation, and
further development?
Should py2exe be integrated into another, larger, package? Pywin32
comes to mind, but also Philip Eby's setuptools (that's why I post to
distutils-sig as well)...
Thomas
Steve M
list looks great, and it appears the developers intend to maintain and
enhance the program indefinitely.
http://pyinstaller.hpcf.upr.edu/pyinstaller
Feature highlights:
* Packaging of Python programs into standard executables, that work on
computers without Python installed.
* Multiplatform: works under Windows, Linux and Irix.
* Multiversion: works under any version of Python since 1.5.
* Dual packaging mode:
* Single directory: build a directory containing an executable plus
all
the external binary modules (.dll, .pyd, .so) used by the program.
* Single file: build a single executable file, totally
self-contained,
which runs without any external dependency.
* Support for automatic binary packing through the well-known UPX
compressor.
* Optional console mode (see standard output and standard error at
runtime).
* Selectable executable icon (Windows only).
* Fully configurable version resource section in executable (Windows
only).
* Support for building COM servers (Windows only).
James Stroud
> What about PyInstaller that was announced the other day? The feature
> list looks great, and it appears the developers intend to maintain and
> enhance the program indefinitely.
>
> http://pyinstaller.hpcf.upr.edu/pyinstaller
That's one short "indefinitely":
Not Found
The requested URL /pyinstaller was not found on this server.
Apache/2.0.53 (Fedora) Server at pyinstaller.hpcf.upr.edu Port 80
James
--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095
Simon John
[snip]
> > http://pyinstaller.hpcf.upr.edu/pyinstaller
> That's one short "indefinitely":
>
> Not Found
> The requested URL /pyinstaller was not found on this server.
> Apache/2.0.53 (Fedora) Server at pyinstaller.hpcf.upr.edu Port 80
It seems that the URL is http://pyinstaller.hpcf.upr.edu
>From the website it seems this is a continuation of McMillan Installer,
which they claim is "far superior" to py2exe! Personally I gave up on
MMI, prefering py2exe on Windows and cx_Freeze on UNIX.
And if they want to use UPX, well that's up to them, but I've had some
problems with it and don't particularly like the thought of runtime
decompression and the two process thing. And when you can compress the
distributable using 7zip or whatever, why bother keeping it compressed
once downloaded?
Ah well, I wish you, whoever takes over py2exe and the PyInstaller guys
the best of luck!
Bugs
[snip]
> * Dual packaging mode:
> * Single directory: build a directory containing an executable plus
> all
> the external binary modules (.dll, .pyd, .so) used by the program.
> * Single file: build a single executable file, totally
> self-contained,
> which runs without any external dependency.
I've never used pyinstaller but even though it can create a single
executable file, doesn't it still write files out to the filesystem to a
temp directory for actual execution? Then cleans them up when the
application quits?
Whereas py2exe can create an executable that NEVER writes any files out
to the filesystem, they are loaded instead directly from the executable?
If so then that's a major difference and IMHO the py2exe method is superior.
Bugs
[snip]
>
> Is anyone interested in taking over the maintainance, documentation, and
> further development?
>
> Should py2exe be integrated into another, larger, package? Pywin32
> comes to mind, but also Philip Eby's setuptools (that's why I post to
> distutils-sig as well)...
>
IMHO, it would be nice if the same folks (or groups working closely
together) maintained both py2exe AND py2app. Then they could share some
code and concepts, create a unified and *consistent* solution on all
supported platforms, etc. Perhaps even creating a Linux version, with
all 3 versions working identically...
Steve Holden
> I'm slowly getting tired maintaining py2exe. It is far from perfect,
> although it has interesting features (I would say).
>
> The problem, apart from the work, is that it is good enough for me - I
> can do everything that I need with it. But I assume I use far less
> libaries than other Python programmers, so a lot of bugs will never bite
> me.
>
> It is also interesting that the recently introduced bundle-files option,
> which allows to build single-file exes has gained a lot of interest -
> although the ONLY use case (so far) I have myself for it is to implement
> inproc COM servers which will compatible with Python clients (and other
> Python inproc COM servers) because of the total isolation of the Python
> VMs.
>
> further development?
>
> Should py2exe be integrated into another, larger, package? Pywin32
> comes to mind, but also Philip Eby's setuptools (that's why I post to
> distutils-sig as well)...
>
your hard work on py2exe over the years, which has benefited the Windows
Python community immeasurably.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.pycon.org
Scott David Daniels
> Thomas Heller wrote:
>
>> I'm slowly getting tired maintaining py2exe. It is far from perfect,
>> although it has interesting features (I would say).
> Ignoring all the philosophical questions I'd like to thank you for all
> your hard work on py2exe over the years, which has benefited the Windows
> Python community immeasurably.
I second this.
--Scott David Daniels
Scott....@Acm.Org
Bob Ippolito
On Sep 20, 2005, at 5:44 PM, Steve Holden wrote:
> Thomas Heller wrote:
>
>> I'm slowly getting tired maintaining py2exe. It is far from perfect,
>> although it has interesting features (I would say).
>> The problem, apart from the work, is that it is good enough for me
>> - I
>> can do everything that I need with it. But I assume I use far less
>> libaries than other Python programmers, so a lot of bugs will
>> never bite
>> me.
>> It is also interesting that the recently introduced bundle-files
>> option,
>> which allows to build single-file exes has gained a lot of interest -
>> although the ONLY use case (so far) I have myself for it is to
>> implement
>> inproc COM servers which will compatible with Python clients (and
>> other
>> Python inproc COM servers) because of the total isolation of the
>> Python
>> VMs.
>> Is anyone interested in taking over the maintainance,
>> documentation, and
>> further development?
>> Should py2exe be integrated into another, larger, package? Pywin32
>> comes to mind, but also Philip Eby's setuptools (that's why I post to
>> distutils-sig as well)...
>>
> Ignoring all the philosophical questions I'd like to thank you for
> all your hard work on py2exe over the years, which has benefited
> the Windows Python community immeasurably.
I'd like to thank you as well. Although I'm primarily a Mac OS X
(and various other *nix-ish things) user myself, I have used py2exe
on several occasions to package a commercial product and to give
various one-off applications to clients.
py2exe was also a large inspiration for py2app (which I have been
neglecting lately). py2exe (and py2app) currently do everything I
need them do (albeit with a little prodding), so that's why I've done
so little with it in the past few months.
I hope that the packager-future will be largely setuptools based and
that the various platform-specific packagers will share a lot more
code in the future (setuptools, modulegraph, etc.), making
maintenance easier and more fun for everyone. This was my primary
use case when I was initially discussing the egg spec with PJE back
around pycon-time (though I have been unfortunately useless
implementing and evolving it).
Right now, I think the packagers and the packages are at odds,
because the packagers need metadata that the packages don't provide
(in a pre-setuptools universe)... so right now users (or the
packagers) need to know a lot of magic incantations to make the
various complicated Python packages work, where with setuptools based
packages the magic incantations are built-in :)
-bob
Giovanni Bajo
>> What about PyInstaller that was announced the other day? The feature
>> list looks great, and it appears the developers intend to maintain
>> and enhance the program indefinitely.
> ...
>>
>> http://pyinstaller.hpcf.upr.edu/pyinstaller
>
> That's one short "indefinitely":
>
> Not Found
> The requested URL /pyinstaller was not found on this server.
> Apache/2.0.53 (Fedora) Server at pyinstaller.hpcf.upr.edu Port 80
Yes, we had a short offline period today due to maintenance on the server,
sorry for that.
--
Giovanni Bajo
Giovanni Bajo
> And if they want to use UPX, well that's up to them, but I've had some
> problems with it and don't particularly like the thought of runtime
> decompression and the two process thing.
UPX compression is totally optional, and it is even disabled by default. For
the log, I have been using UPX for many, many years and never had a problem
whatsoever, but surely there had been bugs.
Nonetheless, if you are so worried about it, I wonder how you can feel
comfortable with py2exe loading up DLLs with his own version of LoadLibrary. It
looks like potentially much more dangerous to me. Or maybe you never build
single-file distributions and you go with single-dir distributions... in which
case there is no "two process" thing.
> And when you can compress the
> distributable using 7zip or whatever, why bother keeping it compressed
> once downloaded?
Some people like the idea of "absolutely no installation process needed".
--
Giovanni Bajo
Giovanni Bajo
> Whereas py2exe can create an executable that NEVER writes any files
> out to the filesystem, they are loaded instead directly from the
> executable?
> If so then that's a major difference and IMHO the py2exe method is
> superior.
To do this, py2exe uses a manually rewritten version of LoadLibrary (the win32
api call in charge of loading DLLs). Since nobody has access to the original
source code of LoadLibrary (across all Windows version), the rewritten version
is by definition incomplete and less stable; it might also be not forward
compatible (that is, your shipped application may break on Windows Vista, or if
you package applications compiled with newer Visual Studio versions).
So it's a trade-off problem. I'm not a fan of writing temporary files to disk,
but surely I prefer this to a potential compatibility headache; an executable
built by PyInstaller will dump some stuff into your temp directory, but it
won't run into compatibility problem when run on that computer or with that
DLL. Anyway, I'm not against adding things to PyInstaller in principle: if
there is enough request for such a feature, we might as well add it.
--
Giovanni Bajo
Garth Johnson
>Ignoring all the philosophical questions I'd like to thank you for all
>your hard work on py2exe over the years, which has benefited the Windows
>Python community immeasurably.
>
>regards
> Steve
>
>
here here! I have just begun my trek into Python and am already relying
upon Py2Exe for my projects. Thank you for an effective, well designed
tool that is easy to use. It was one of the final deciding factors in
our company's choice of languages. (not the least of which was the ease
of which our dev team took to Python after pretzling with perl). I do
hope you change your mind.
Garth
keithlackey
DECLARING CLASS
class structure:
def __init__(self, folders = []):
self.folders = folders
def add_folder(self, folder):
self.folders.append(tuple(folder))
Now I try to make an instance of this class
structure1 = structure()
structure1.add_folder([('foo'),])
print structure1.folders
This returns: [('foo',)]
This works fine. But when I try to make another instance of that class...
structure2 = structure()
print structure2.folders
This now also returns: [('foo',)]
Even though I haven't added any folders to this new instance
What am I doing wrong?
Sybren Stuvel
> def __init__(self, folders = []):
> self.folders = folders
Read all about this very common mistake at
http://docs.python.org/tut/node6.html#SECTION006710000000000000000
> def add_folder(self, folder):
> self.folders.append(tuple(folder))
The line above has a combination of spaces and tabs. Use either spaces
or tabs, but not both, to indent your code.
Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
Larry Bates
a mutable as default value in your argument list for __init__.
See:
http://www.nexedi.org/sections/education/python/tips_and_tricks/python_and_mutable_n/view
It would be better to write:
class structure:
def __init__(self, folders = None):
self.folders=folders or []
-Larry Bates
Scott David Daniels
> I'm relatively new to python and I've run into this problem.
First, as noted by Sybren, messages should just use spaces in order to
be readable.
After correcting that one:
> class structure:
> def __init__(self, folders = []):
> self.folders = folders
> ...
Here is the second one. Default args are not rebuilt, but shared.
The correct way to do this is:
class structure:
def __init__(self, folders=None):
if folders is None:
self.folders = []
else:
self.folders = folders
...
--Scott David Daniels
Scott....@Acm.Org
Lucas Raab
*motion passed for entry into Python Hall of Fame*
--
--------------------------
Lucas Raab
lvraab"@"earthlink.net
dotpyFE"@"gmail.com
AIM: Phoenix11890
MSN: dotpyfe "@" gmail.com
IRC: lvraab
ICQ: 324767918
Yahoo: Phoenix11890
Bugs
a GREAT project and would be a shame to see it fall into obsolescence.
Thomas Heller wrote:
[snip]
>
> Is anyone interested in taking over the maintainance, documentation, and
> further development?
>
[snip]
Thomas Heller
> Any luck on finding anyone to take over py2exe development Thomas?
> It's a GREAT project and would be a shame to see it fall into
> obsolescence.
No, nobody stepped up (yet).
Thomas
Bugs
the same umbrella? I don't know what the status of py2app is or who
maintains it but I was thinking that it would be ideal if the 2
utilities could share code, ideas, protocols, etc. Seems like this
synergy and consistency would be very beneficial. Perhaps then a Linux
version could be developed with an identical inferface.
Thomas Heller
>> Bugs <do...@spam.me> writes:
>>
>>>Any luck on finding anyone to take over py2exe development Thomas?
>>>It's a GREAT project and would be a shame to see it fall into
>>>obsolescence.
>> No, nobody stepped up (yet).
>> Thomas
Bugs <do...@spam.me> writes:
> What do you think of the idea of putting both py2exe AND py2app under
> the same umbrella? I don't know what the status of py2app is or who
> maintains it but I was thinking that it would be ideal if the 2
> utilities could share code, ideas, protocols, etc. Seems like this
> synergy and consistency would be very beneficial. Perhaps then a
> Linux version could be developed with an identical inferface.
That's not a bad idea. Philip Eby even suggested to put something like
py2exe's modulefinder (well, it's really Python's) and py2app's
modulegraph into his setuptools package - although I didn't respond at
that time.
Anyway, these are changes that I don't want to do myself. Whoever wants
to start that feel free...
Thomas