OT: automatically building minimalist installers for Windows?

wxPython Users
1

Hi all--

A little OT, but I'm clueless about Windows: right now our wxPython
app is installed using a primitive command-line self-extracting .zip -
basically it just unwraps the archive in whatever directory it's run
from, runs a few batch scripts, and exits. Not surprisingly, this is
proving difficult to support, and prone to unexplained problems - the
only reason we're doing it this way is that it's easy to script, and
we build a new installer nearly every night. I'd like to come up with
something simpler for our users, specifically:

1. The install location is fixed, e.g. C:\MyApp-1.2-4567; this allows
us to skip running the batch scripts, which configure the program for
a particular location. (This isn't ideal, but our app is massive and
horrendously complex and we're stuck with this.)
2. The installer does not need to run any special programs - all I
need is for it to unwrap the package in C:\.
3. Very important: the installer needs to look more or less like any
other Windows installer, i.e. double-click the package, click a few
buttons (maybe with a README or license, but not essential), and it's
done. I guess this means .msi format, but I'm pretty unclear about
details.

In order for this to be maintainable, however, I need to be able to
script the entire process and run it unattended. If this is something
that can be done from Python, great, but I'll deal with batch scripts
if necessary.

I know this should all be possible, but Google is turning up far more
information than I need, and the tutorials all appear to be specific
to "native" Windows programs, i.e. developed with Visual Studio, and
they mostly deal with graphical tools. Does anyone have any pointers
for an impatient Unix programmer?

thanks,
Nat

2

A lot of folks like InnoSetup, and is also what I use for wxPython. It has a command line 'compiler' that can be used to build the self-installer. If you need it the installer can include some pascal code, along with a small pascal interpreter, which can do more advanced things if needed on the target.

···

On 4/19/12 12:09 PM, Nat Echols wrote:

Hi all--

A little OT, but I'm clueless about Windows: right now our wxPython
app is installed using a primitive command-line self-extracting .zip -
basically it just unwraps the archive in whatever directory it's run
from, runs a few batch scripts, and exits. Not surprisingly, this is
proving difficult to support, and prone to unexplained problems - the
only reason we're doing it this way is that it's easy to script, and
we build a new installer nearly every night. I'd like to come up with
something simpler for our users, specifically:

1. The install location is fixed, e.g. C:\MyApp-1.2-4567; this allows
us to skip running the batch scripts, which configure the program for
a particular location. (This isn't ideal, but our app is massive and
horrendously complex and we're stuck with this.)
2. The installer does not need to run any special programs - all I
need is for it to unwrap the package in C:\.
3. Very important: the installer needs to look more or less like any
other Windows installer, i.e. double-click the package, click a few
buttons (maybe with a README or license, but not essential), and it's
done. I guess this means .msi format, but I'm pretty unclear about
details.

In order for this to be maintainable, however, I need to be able to
script the entire process and run it unattended. If this is something
that can be done from Python, great, but I'll deal with batch scripts
if necessary.

I know this should all be possible, but Google is turning up far more
information than I need, and the tutorials all appear to be specific
to "native" Windows programs, i.e. developed with Visual Studio, and
they mostly deal with graphical tools. Does anyone have any pointers
for an impatient Unix programmer?

--
Robin Dunn
Software Craftsman

3

You might want to check out Andrea's gui2exe.

It generates the setup.py script to freeze your application and it can also generate at least a skeleton InnoSetup script.

http://code.google.com/p/gui2exe/

Werner

···

On 19/04/2012 21:09, Nat Echols wrote:

Hi all--

A little OT, but I'm clueless about Windows: right now our wxPython
app is installed using a primitive command-line self-extracting .zip -
basically it just unwraps the archive in whatever directory it's run
from, runs a few batch scripts, and exits. Not surprisingly, this is
proving difficult to support, and prone to unexplained problems - the
only reason we're doing it this way is that it's easy to script, and
we build a new installer nearly every night. I'd like to come up with
something simpler for our users, specifically:

1. The install location is fixed, e.g. C:\MyApp-1.2-4567; this allows
us to skip running the batch scripts, which configure the program for
a particular location. (This isn't ideal, but our app is massive and
horrendously complex and we're stuck with this.)
2. The installer does not need to run any special programs - all I
need is for it to unwrap the package in C:\.
3. Very important: the installer needs to look more or less like any
other Windows installer, i.e. double-click the package, click a few
buttons (maybe with a README or license, but not essential), and it's
done. I guess this means .msi format, but I'm pretty unclear about
details.

In order for this to be maintainable, however, I need to be able to
script the entire process and run it unattended. If this is something
that can be done from Python, great, but I'll deal with batch scripts
if necessary.

I know this should all be possible, but Google is turning up far more
information than I need, and the tutorials all appear to be specific
to "native" Windows programs, i.e. developed with Visual Studio, and
they mostly deal with graphical tools. Does anyone have any pointers
for an impatient Unix programmer?

4

I agree with Robin and Werner. Use GUI2Exe to create the setup.py you need. Then you can write a script to automate py2exe (or cx_freeze or whatever) for the freezing bit. I wrote an article about using InnoSetup to package up a wxPython program of mine quite a while ago. You might be able to use it for some pointers: Packaging wxPyMail for Distribution - Mouse Vs Python

I think I have a script around here for generating my InnoSetup script file too, but I’ll have to go digging for it when I get home.

  • Mike
···

On Thursday, April 19, 2012 2:09:44 PM UTC-5, Nat wrote:

Hi all–
A little OT, but I’m clueless about Windows: right now our wxPython
app is installed using a primitive command-line self-extracting .zip -
basically it just unwraps the archive in whatever directory it’s run
from, runs a few batch scripts, and exits. Not surprisingly, this is
proving difficult to support, and prone to unexplained problems - the
only reason we’re doing it this way is that it’s easy to script, and
we build a new installer nearly every night. I’d like to come up with
something simpler for our users, specifically:

  1. The install location is fixed, e.g. C:\MyApp-1.2-4567; this allows
    us to skip running the batch scripts, which configure the program for
    a particular location. (This isn’t ideal, but our app is massive and
    horrendously complex and we’re stuck with this.)
  2. The installer does not need to run any special programs - all I
    need is for it to unwrap the package in C:.
  3. Very important: the installer needs to look more or less like any
    other Windows installer, i.e. double-click the package, click a few
    buttons (maybe with a README or license, but not essential), and it’s
    done. I guess this means .msi format, but I’m pretty unclear about
    details.

In order for this to be maintainable, however, I need to be able to
script the entire process and run it unattended. If this is something
that can be done from Python, great, but I’ll deal with batch scripts
if necessary.

I know this should all be possible, but Google is turning up far more
information than I need, and the tutorials all appear to be specific
to “native” Windows programs, i.e. developed with Visual Studio, and
they mostly deal with graphical tools. Does anyone have any pointers
for an impatient Unix programmer?

thanks,
Nat

5

I'll defer to those with more experience, but the approach I've taken
in the short term is to write just enough of a Windows batch script to
install Python and then kick off a Python script to install the rest.
At the end, it launches my wxPython app. You can do a lot with the
subprocess module and various built-in Windows subsystems like WMIC.
Dependencies include wxPython, PostgreSQL, psycopg2, pyserial, and a
few other FOSS packages that can all be installed using CLI commands
with appropriate switches to hide individual GUI installers.

Dan

···

On Apr 19, 3:09 pm, Nat Echols <nathaniel.ech...@gmail.com> wrote:

In order for this to be maintainable, however, I need to be able to
script the entire process and run it unattended. If this is something
that can be done from Python, great, but I'll deal with batch scripts
if necessary.

6

To tell you the truth. I do not understand your problem
and I do not even understand what can be the problem. You
did not give enough informations.

Several points.

For an already installed Python environment, distributing
the bunch of .py files with a zip file is certainly the
most obvious, simple and flexible way to do the job.
It is not even necessary to have to use an unzipping utility.
On Windows (since ?) a zip file is a directory. Unzipping is
practically a xcopy.

A Python application, a "main.py" can be "installed"
everywhere, in any directory (hd, external hd, cdrom, usb
key, ...) and can be used from any working directory.

That was for the deployment. Now, launching a Python
application is a different process. Basically, it is
a no problem. If you wish to help your end users with
menu entries, desktop icons, a license display and so on,
msi or InnoSetup are the tools to be used or may be mandatory
for special cases like COM servers).

If it has to be an automated process (I have no experience on
that field), I do not see how a xcopy or an unzip could fail.
The troubles may come from the confusion between installing/
deploying and lauching the application.

A personal point of view

- InnoSetup does have a sense for "large" and/or "utilities"
applications like wxPython. In most of the cases, it is just
superfluous.
- I'm really happy, I can use thousands of Python scripts,
without having to install them.
- If somebody proposes an application and ask for testing and
if the first think I have to do is to *install* it (when a simple
xcopy would have been enough), I simply pass my way.
- Maybe the most important point. I'm always distributing
my apps, can be a bunch of .py, .txt, .html files or the
bunch of the files created with py2exe or cx_freeze in a zip
files. I never succeded to find an end user not beeing able
to unpack these files and to start the application.
I'm even always insisting on the fact, that if they want to
remove the application, it is just a question of deleting files.
In many cases, what I'm telling is not even true. I'm only giving
away the dir containing the application.
I never succeeded to make this more simple and/or user
friendly.

jmf

···

On 19 avr, 21:09, Nat Echols <nathaniel.ech...@gmail.com> wrote:

Hi all--

A little OT, but I'm clueless about Windows: right now our wxPython
app is installed using a primitive command-line self-extracting .zip -
basically it just unwraps the archive in whatever directory it's run
from, runs a few batch scripts, and exits. Not surprisingly, this is
proving difficult to support, and prone to unexplained problems - the
only reason we're doing it this way is that it's easy to script, and
we build a new installer nearly every night. I'd like to come up with
something simpler for our users, specifically:

...

7

The problem, simply put, is that we have a huge mess of code, mostly
Python and (compiled) C++ with a handful of shell or batch scripts,
plus several hundred GB of accessory data, and it is impossible to
package into a simple .exe file. An additional limitation is that the
path to the installation needs to be hardcoded into a variety of
files; without this, the system won't work. This leaves us with two
obvious methods of installing the package:

1) Run a bunch of scripts to unpack the distribution and regenerate
the files which directly reference the installation path. This isn't
as much work as it sounds, because we already wrote most of these
scripts to build and test the package in the first place, so only a
few extra scripts are required to make the installer.

2) Require a fixed location (/user/local/MyProgram,
/Applications/MyProgram, or C:\MyProgram), and provide a simple
graphical wrapper which installs the package into this location.

On Linux, we use (1), which works okay in practice (most of the
problems result from Linux library versions not matching up); on Mac,
we can use either (1), with the exact same scripts we use for Linux,
or (2), using some hacked-together scripts that run Apple's
PackageMaker utility. (Which, it needs to be said, is incredibly
buggy, but at least I'm used to developing on Macs.) On Windows, we
are currently stuck with (1), but it is strange and unfamiliar to most
Windows users, and in practice tends to fail in unpredictable ways.
So I'd like to figure out a way to stuff the entire mess
(approximately 1.8GB) into a .msi file with as few "moving parts" as
possible.

I know this isn't an ideal design by any stretch of the imagination,
but I'm inheriting a setup that's more than a decade old, and I lack
both the time and the political capital to engineer a change. In an
ideal world we could ignore the existence of Microsoft products
entirely - sadly, many people in our field are switching to Windows
systems.

-Nat

···

On Sat, Apr 21, 2012 at 8:04 AM, jmfauth <wxjmfauth@gmail.com> wrote:

To tell you the truth. I do not understand your problem
and I do not even understand what can be the problem. You
did not give enough informations.

8

Thanks, I think that's exactly what I needed - looks like it'll take
forever to compile, but we run our builds overnight anyway.

-Nat

···

On Fri, Apr 20, 2012 at 1:47 PM, Mike Driscoll <kyosohma@gmail.com> wrote:

I agree with Robin and Werner. Use GUI2Exe to create the setup.py you need.
Then you can write a script to automate py2exe (or cx_freeze or whatever)
for the freezing bit. I wrote an article about using InnoSetup to package up
a wxPython program of mine quite a while ago. You might be able to use it
for some pointers:
Packaging wxPyMail for Distribution - Mouse Vs Python

9

Personally I would attempt to get away from the fixed path(s) ASAP -
many users are finding that they are running short of space on C:
and are using either D:/ or Network or external drives also with the
rapid gain in popularity of tablet computers being able to carry
your software on an SD card would be a major advantage.

One of:

  •     Relative paths, (i.e. replacing C:\MyApplication with .\

    everywhere but start-up shortcuts),

  •     Reading the installation path from a configuration entry

    everywhere it is used,

  • Reading the working location from a file,

  • Reading the working location from an environment variable.
    is normally a very simple change and the latter options something
    such as Innosetup can generate the configuration entry/file at
    install time. Pointing out that the ability to run from various
    locations will greatly enhance the accessibility of your program
    plus allow you to support multiple versions on a single machine
    may enhance your political capital.

    I would at the same time look to see if it is possible to have a

data file(s) location stored using one of the above possibilities
this would let you install different versions of the code with a
single data set, (and vice versa), again greatly enhancing the
support options.

  The other thing that I would look at would be whether it is

possible to package the data and software separately, i.e. all
the, probably quite rarely changing, data/support files in a zip
that is unzipped and installed to the data location by a post
install script/exe and the actual software in a much smaller
installation bundle, this would drastically cut your install time
and possibly allow you to have a single distribution for
Windows/OSX/Linux on a single set of media which could also score
you some points internally as well as with the customer(s).

Gadget/Steve

···

wxjmfauth@gmail.com