Is there a small Python runtime environment installer?

[Tex Riddell]

"David Bolen" <db3l at fitlinxx.com> wrote in message
news:uwv1sik4n.fsf at ctwd0143.fitlinxx.com...
> tex_r at hotmail.com (Tex Riddell) writes:
>
> > More specifically I'm looking for something for the windows
> > environment, but one should be able to make something like this
> > multi-platform, right?
>
> Well, you'd have a harder time having a portable distribution if you
> were looking for a binary, sort of by definition.

I detect a hint of sarcasm here.  Of course, that's not what I meant.  I
meant binary installers for each platform that would set up a similar
environment for running your scripts in, regardless of end-user's platform.

> But since you're specifically targetted at Windows, why not just use
> the standard Windows installer?  It lets you ignore the examples and
> documentation and just install the core stuff if you like.  Any
> Windows user should be completely at home with the installation
> process.

I was just looking for something smaller and simpler.  If you read further,
I mention clumping/compressing multiple files into single archives to keep
things reasonable small.  I don't expect to have to sit over the shoulder of
the user who is installing a python distribution and tell them to de-select
this, and that, oh, and that, drill down, and this and that...  I just want
a simple, configurable, re-distributable runtime.  Because of scripts,
utilities and the like, the default ActivePython installs about 24 megs of
stuff in so many files that depending on the file system could take up as
much as 70 megs of space on the user's HD.  That's a little much to ask just
so they can run a little utility script I want to send them.

> > How can we expect python to become more mainstream if only developers
> > can understand the environment that must be set up for scripts to run?
>
> At least under Windows, I don't think installing Python is any harder
> than installing any other application.  That's largely true as well on
> various Unix platforms, since there are rpms and other install
> packages written for Python to conform to local platform expectations.

You missed my point, if you are installing office, you would be expected to
know what office *is*, therefore knowing what options you want and do not
want installed.  When my friend is installing Python, all they know is that
it is something that'll make the stuff I send them run.  They will select
default installation, because they couldn't know any better.

> > I really don't have time to learn distutils (re-inventing the wheel
> > that I'm sure so many have done) in order to install a runtime
> > environment on someone's machine so they can run a simple 8k script.
>
> Of course, those same people (under Windows) have already installed
> MBs of common code just so they can run small VB applications, whether
> via their initial Windows installation or updated silently in other
> stuff they may have installed. :-)

True, however, most of that common code is used by Python as well!  Only
specific parts are specific to VB.  Those parts won't necessarilly just *be*
on a host machine.  This is the runtime library that must be installed.  VB,
however, has the advantage that it produces executables that just look for a
runtime dll when run.  This is quite a bit simpler than with python, having
to set up additional paths and environment variables to make .py files
executable.


> BTW, there is also the option of constructing a standalone
> installation (for Windows, look into the py2exe or installer packages,
> and installer also handles Linux) for your script.  For Windows, it
> would include the Python DLL and appropriate lib files all packages
> into a single file or collection of files that you could then
> distribute independently of any other.  On the Windows platform if you
> combine that with an installer - like the free Inno Setup - you'd end
> up handing your script to your friend as a normal Windows installation
> program that took care of installing everything.

I am aware of this option, but as my script is a small simple shell script,
not a stand-alone GUI app, if I wanted to send more scripts, I would have to
build more installers!  These seem to only try to track the dependencies of
a single application, then bundle only these parts in the installation.  I'm
not prepared to write a setup program just to install a utility script...
I've wasted too much time on this already!

> Of course, this would be much larger than an 8K script and would thus
> be hellishly less efficient if you were sending a lot of scripts this
> way (as opposed to just having him install the runtime one time), but
> for a one-shot deal it would make the receiver's life simple.

exactly!  Do you at least understand what I'm trying to get at?  Imagine
python was like html.  End users typically have a web browser that includes
a set of standard features built around the standard.  Those end users need
not install development kits in order to view an html file.  They simply
download a web browser.  Also people distributing an html file wouldn't need
to build a browser around their file that included only the features that
thier file used and send it to the user!

-Tex