Distributing Python apps

[David Bolen]

"Norman Skrzypinski" <zypin at sympatico.ca> writes:

> I'd like the software to be available to anyone who has a floppy disk and
> access to a computer.  My first target is the largest group, Windows users;
> but, I don't want to ignore the people who have Mac and Linux.  To me,
> that's one of the many attractions of Python - everyone can use it.
> 
> A rough draft of my first two applications, written in Visual Basic,
> produced .exe files that are 350-460 KB.  The complete application would
> probably be about 750 KB.  A data file, for 12 months, for a typical user,
> would be about 500 KB.  So, the entire app and one year's data would easily
> fit on a floppy disk, and could be used at home, school, work, or the
> library.

You might have a problem with the single floppy and Python, depending
on the modules that you make use of (and in particular if you involve
a GUI or not).  You'd probably have to target a mode where the
application got installed on the hard drive, but the floppy was used
for data transport.

In my case, a Python 1.5.2 application with wxPython 2.2.1 as the GUI,
resulted in a single .EXE installer of about 2MB and an installed size
in the 5MB range.  Moving up to Python 2.2 and wxPython 2.3.x would
undoubtably grow that a bit.  So you really couldn't fit even the
installer on a single floppy (although 2 is fine).  That includes a
256K data file that is part of the application.  Now, wxPython is a
fairly large DLL (and can't really be segmented based on your specific
needs unless you rebuild from source); I think a Tk based application
might shave a MB or so off of the installed size.

I'm a little surprised at your VB sizes though, given that at least on
my system, the basic runtime file (msvbvm*.dll) was over 1.3MB for
both VB 5.0 and 6.0, so it would seem to me that you couldn't fit your
VB application on a diskette either.  You might be able to fit an
installer, but you'd need the files expanded somewhere for actual
execution.  Unless you're assuming the user already has the runtime
installed (granted, for VB that's somewhat safe), in which case you're
comparing apples to oranges since the Python numbers include the
runtime while the VB numbers don't.

Taking a quick glance at an old VB 6 application that we also
distribute, using the VB packager ended up with a 140K setup.exe and a
1.9MB primary .CAB file.  Now, some of that space was a large help
file, but the majority was the RTL (msvbvm60, some ole* files, the
common controls, etc...), so even without the help file I don't think
it would fit on a floppy.  And that's just the installer - not a
version you could execute from the floppy.

Heck, getting a full application onto a single floppy including
runtime is probably difficult in most any language nowadays (you could
probably do it with pure C/C++ as long as you stuck with raw Win32 and
not MFC).  So you're left assuming some of your language runtime is
already present on the target system - which therefore tips the scales
in the direction of stuff already likely to be present on a Windows
system (e.g., Microsoft development languages).  Even that may be
risky though - e.g., older systems may not have a VB 6.0 runtime,
although if they've updated any number of standard applications it
probably came along for the ride.

Note that this problem even exists with newer MS environments.  If you
wanted to do any .NET stuff (VB .NET, C#, etc...) you'd either have to
distribute the .NET CLR with your application or make the user install
it first.

In short, if your goal is to have an executable that can run from a
floppy, I think you have to assume that the runtime needed by that
executable will already be on the systems.  You'll thus minimize your
risk (but not negate it) by using something like VB or VC since the
odds are with you the needed runtime is present.  But if you instead
plan a process where the runtime is a separate installation on the
target machines, then Python would be as efficient (and probably even
more so) in terms of size for distribution of the final application.

> Downloading and installing Python on every user's machine is not acceptable,
> to me.

I read this as you're already assuming that installing something like
the VB runtime is acceptable.  I won't claim that's unfair, since
that's just the way the world is (that's an entrenched runtime likely
to already be present and/or machines are more likely to silently keep
getting VB runtime updates without them knowing), but I do think you
need to recognize the assumption.  And if that's a block to using
Python, it's certainly a fair point.

> PS:  I quite strongly disagree with the nutritional advice given by your
> company.

I'm not really involved with that side of things (I'm tech, not
nutrition - it's content generated by external "experts") but feel
free to provide feedback through the site to anything you disagree
with - can't say it's all that surprising to see debate about diets
and nutrition.  Personally, I'm a moderate-carb guy :-)

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/