Re: (updated) Choosing a collection of common modules/packages for a general purpose reusable PY2EXE runtime

[pyt...@bdurham.com]

We've decided to build a re-usable *general purpose* PY2EXE
"runtime" that can be shared by a number of scripts vs.
distributing a monolithic EXE for each of our scripts.

A list of the Python 2.6.4 compatible modules/packages we decided
to include (and exclude) in our "runtime" follows my signature.

Any suggestions on additions or deletions appreciated.

Thanks,
Malcolm

3rd party modules/packages:
- jsonpickle
- wmi <--- forgot this one in my original post
- win32api
- winshell

We've included all modules from the Python standard library
EXCEPT the following:
http://www.python.org/doc/2.6.4/modindex.html
- aifc
- audioop
- bsddb
- Carbon
- dbhash
- distutils
- dumbdbm
- netrc
- plistlib
- robotparser
- ScrolledText
- shelve
- sunau
- tabnanny
- Tix
- Tkinter
- turtle
- whichdb

[Aahz]

In article <mailman.491.12681448...@python.org>,

<pyt...@bdurham.com> wrote:
>
>We've decided to build a re-usable *general purpose* PY2EXE "runtime"
>that can be shared by a number of scripts vs. distributing a monolithic
>EXE for each of our scripts.

It's not clear what the purpose of this is. You can build several
scripts against the same py2exe backend.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer

[pyt...@bdurham.com]

Aahz,

>> We've decided to build a re-usable *general purpose* PY2EXE "runtime"
>> that can be shared by a number of scripts vs. distributing a monolithic
>> EXE for each of our scripts.

> It's not clear what the purpose of this is. You can build several
> scripts against the same py2exe backend.

Yes you can, but with our technique we only build and distribute our
py2exe backend *once*.

Our goal was to build a custom Python runtime that we could build and
deploy once and then augment with the many scripts we distribute and
update. By including the full Python standard library (minus non-Windows
and certain deprecated modules) and a few additional 3rd party
modules/packages (win32, wmi, jsonpickle, etc) our script distribution
has become significantly easier, faster and more robust - especially for
scripts that may make dynamic module imports missed by py2exe. Script
updates are incredibly fast because our clients only download the
scripts themselves (packaged as standalone zip files). Not that disk
space is a concern any more, but our client footprint is significantly
smaller without every script being a single file exe.

I recognize that this technique might not work for everyone, but it has
worked out extremely well for us.

Malcolm

--
http://mail.python.org/mailman/listinfo/python-list