[Distutils] [Py2exe-users] Re: Getting tired with py2exe

[Phillip J. Eby]

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