packaging TiddlyWeb, a pure Python application

It's not suitable for distribution of other programs though, only really for development of programs and running things from source. Reread my response concerning multiple versions and libraries.

I'd been thinking more along the lines of putting Python in CommonFiles and any extras in the application's directory, something like App\PythonPath (or another directory in CommonFiles for a large one which is used by more than one thing, like wxWidgets, which would automatically then get added by the launcher to the PYTHONPATH environment variable so Python would find it. The problem with that was that site-packages could still be located and written to by a Python script - anyone trying to easy_install something would end up with things in the wrong place without a bit more fiddly Python code to change its impression, which I hadn't looked at yet. I've heard of virtualenv but never thought to look at it... thanks, it looks like it might do a better job with it. Some time I may see about making a Python segment for the PortableApps.com Launcher and a shared Python package (I think I'd do 2.5, 2.6 and 3.0 branches).

Applications like Blender still wouldn't be able to use this shared Python though; they must use their own binaries, to a large extent at least (though Inkscape, another such, could probably work with a different Python in the PATH, I think).

The argument of this post is size rather than complexity.

The problem I see is that some applications require a specific version of Python; generally it's ">= 2.3" (or 2.4 or 2.5) but there are things which break with 2.5, and so for them you'd end up having to have a Python 2.4 environment. I like to do size comparisons in most of these things; while I don't have all the statistics as I haven't tried to get them, the gist of it is:

• A CPython environment tends to end up somewhere around 20MB installed or maybe more.
• CPython gets compressed pretty well when used with py2exe (most applications don't use bundling and compressing as efficiently for small size as they could; I enhanced my brother Ben's BPBible build script to flip the right switches, so BPBible's make_setup.py script is the best for showing how to shrink the Python environment that there is). It can come down to under 5MB I think. wxPython is then more, and in BPBible's case the SWORD bindings are even more still, which is why BPBible is so big (about 20MB portable).
• To continue this BPBible example; the required environment for running from source would be Python 2.5 (OK, we could use 2.6) plus wxPython 2.8.9 plus SWORD 1.5.9 plus PyStemmer. I would assume we would have CommonFiles\Python and CommonFiles\wxPython (as wxPython is fairly big, and shared between many applications, e.g. Task Coach would also use both) and then BPBiblePortable\App\BPBible\pymodules to contain libsword and pystemmer. PYTHONPATH manipulation to manage this sort of thing is easy enough. The size is much bigger than the compressed variant you get with py2exe. Here are some estimates (no figures to back them, feel free to analyse it more accurately and correct me if you want):
  • Running from source: Python = 12MB, wxPython = 10MB, SWORD = 4MB, PyStemmer = trivial, source = 3MB (including required base resources, graphics et al): estimated total: ~30MB. For the second wxPython application then, maybe another 5MB added [Task Coach?]. BUT: it's quite possible that they won't use another Python application which can use this shared runtime.
  • py2exe generated: BPBible: 13MB; Task Coach: 25MB. With both, it may possibly end up a bit bigger, but you get fewer files, and maintenance is a lot easier.
• There's also the issue of how you distribute the Python files; .py, .py+.pyo or just .pyo (I'm saying o rather than c as it's slightly optimised)

This post is very bitsy... don't expect to get much useful out if it. The biggest problem in my opinion is forcing a CommonFiles directory. It makes the whole process much less flexible (not necessarily bad) and more fiddly for the user.