<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.

On 21-sep-2005, at 2:59, Phillip J. Eby wrote:

<trimming a few lists from my reply>

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

Relying on the system python might not be a smart thing to do. Apple is taking backward compatibility seriously, but not always for the unix-y bits. That may or may not include Python. It would be rather annoying if an application did depent on the system python and Apple decided to ship another release of python.

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

Building something py2app-ish is easy enough: take py2app and hack it until it fits into your scheme. I've done this at work to build standone unix daemons and that wasn't very hard. Ronald