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. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.pycon.org

<trimming a few lists from my reply> At 07:12 PM 9/20/2005 -0400, Bob Ippolito wrote:

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 :)

Also, my outsider-observation of both py2exe and py2app is that they are significantly complicated by the attempt to select and distribute only a subset of the Python standard library. If you can live with just putting the entire stdlib in a zipfile, or relying on a locally-installed Python (e.g. via the .msi on Windows, or the system-provided Python on OS X) then the build process is a lot simpler. The latest setuptools does .exe wrappers for console scripts, and will soon have them for GUI scripts. Basically, if you want to build your package to a "single-directory deploy" with setuptools, you can do: python setup.py easy_install -ad deployment_directory . where deployment directory is the directory that you'll distribute. The -a is short for --always-copy, which means to copy all required eggs to the target directory whether they're already on sys.path or not. The script directory defaults to the -d directory, so the .py files and .exe wrappers for console scripts are generated there as well, but the .py files will be set to execute via the same Python you ran the above command with. So, if you wrap the directory up with an installer that also installs the Python version you depend on, you're basically done, at least for Windows. It's not perfect, I'll admit. You can't get that nice "drop the .exe in a directory and it's set to go" feeling. In principle I suppose you could cram the python DLL and stdlib zip and the needed modules all into one .exe file, but it seems counterproductive for the end user to have a dozen copies of Python on their machine, even with stripped-down stdlibs. DLL hell doesn't get into it because everything's versioned. Frankly, it seems to me like having an all-purpose egg installer that installed Python and put the eggs in a shared location would be even better, since applications with eggs in common wouldn't need them downloaded more than once. The trick to that is of course that somebody's got to write that installer. :) On Linux and the BSD's, it suffices to package your eggs and the Python they depend on, so distributing the result of 'easy_install -ad' is adequate for binary-compatible installs. Or, you can rely on the local packaging system to have the packages that install the eggs you need when you install a package for your app. The only tweak possibly necessary is the #! paths in the scripts. That leaves OS X, where I gather that convention and policy dictates that applications just be runnable without an install step. There you can bundle all your eggs, and rely on the system Python, as long as it's recent enough. Ideally, then, you need a wrapper for the "easy_install -ad" directory that makes one or more real OS X apps, in the way that setuptools makes .exe wrappers now. (Only more complex, since all it really does right now is copy and rename a standard launcher .exe file.) So, it seems to me that if you can rely on Python and the stdlib, the scope of what a py2exe or py2app tool has to do in the setuptools context is at least somewhat reduced. However, there's definitely a need for other developers to be involved, because with my current amount of spare time, it'll be a year or two before I could even think about doing anything py2app-ish. (I don't even have a Mac yet, for example.) It's possible I might get some support for OSAF for some of this, in which case my time and resources would be increased, but I haven't broached that subject yet. It's very likely that Chandler will be egg-based, but it's not clear to me yet whether that will be going all the way down to the .exe/.app/.so and installer level or not. But having a way that we could build Chandler executables for Windows, Mac, and Linux with a single (and relatively simple) setup.py would be very nice, and even better if it meant anybody could do similar single-setup cross-platform deployment.

Steve Holden wrote:

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