Windows distribution suggestions?

[Bernhard Holzmayer]

Paul Rubin wrote:

>> Since your installer needs to run before Python is installed, you need
>> something else. Go to http://www.wisesolutions.com
>> You'll find a Windows installer program, with a demo-version (30days
>> license). Try this, it would be my best recommendation.
> 
> Hmm, ok, it looks like the paid version is around 500 USD.  Since this
> is a Windows thing I'm ok in principle with using a payware packaging
> app, but that's a bit on the expensive side.  I'll see what the
> customer says but I think they might resist.

1) Maybe you can start with the 30days demo license to find out.
2) The high price is paid for the benefit, that you won't get lost inside
the terrific installation jungle like registry, access restrictions, dlls
etc. In the end, it's your benefit, not your customer's.
If I were the customer, I'd demand a fluent installation process at no cost
and without any risk and/or conflict with other installed software. 
If I were the developer (you), I'd compare all costs/times with that price.
If you calculate one hour for let's say 25 USD, the question is: will it
save you 20 hrs. I guess so. If you have spare time, it doesn't get paid.

> The app works ok under Windows now.  
Congratulations.
> I don't use ODBC.  I might need some database connectivity later and will
probably use MySQL.  
Then you'll probably use ODBC, since the MySQL server will probably not be
run under Windows and on the same machine. 
> I don't want to need an admin account.  
Nobody wants that. It just happens...
> Right now the app just has a Tkinter gui, 
That's safe in general, and probably a good choice.
> reads and writes a few files and talks to some sockets.  
Not that trivial! Plan enough time for testing.
And, if you install without sophisticated tool, reserve enough time for
troubleshooting and modifications...
 
> The program is under active development and sprouting new features
> every few minutes.  The idea is to release a new development build once
> a week or so, for internal use by the customer.
If the customer runs it on different machines, make sure that you always
have one installation around where you work, which is exactly as the one at
the customer's site. If the customer is able to run different versions at
the same time, keep one living copy of every possible version.
Hunting bugs while you have lost the overview of the versions, will haunt
you in the end...
> 
>> If your application has a GUI, a menu entry might fetch your update files
>> and place them wherever they must reside. your update.py might feed that
>> menu entry. Quite easy.
> 
> Hmm, that's another thing I'd have to code--maybe it's feasible.  I'll
> think about it.
Have a look at one of the Adobe Acrobat Reader's newest versions. They do
this. Indeed, it doesn't work on my computer, but that's the idea...

> No I'm really ignorant about Windows.  I just put the app's files in
> C:/Program Files/appname because that's what one of the other developers
> said to do.

Don't do that, despite what the others say. You may propose that, but in any
case give the installer the choice to change it.
Lots of people use different partitions which separate Windows / Programs /
Data. In other countries even Windows uses different path names (e.g. here
in Germany C:/Programme). According to Microsoft's Technical Reference,
you'd better ask the registry to find out where applications usually
reside. (That's what professional installation software does.)

I guess that neither your apps nor Python requires special folders or paths,
so don't impress this disadvantage artificially.
Vice versa: don't ask for another drive/partition, because some users have
only C:/... 

> 
>> > I do have Visual C++ installed on the development machine, if that
>> > helps.
>> 
>> Isn't Visual C++ still coming with a restricted version of InstallShield?
>> If so, check if you can use that. It might give your release a sort of
>> professional shine...
> 
> Hmm, that's really really interesting.  How would I find out?
Check the installation. Your StartMenu should show the appropriate entry
under VisualStudio/...tools... If not, maybe you forgot to install it.
Or, it's gone away like some other precious tools...
> 
>> You'll certainly find out, that managing the registry/desktop file system
>> will cost most energy, if you want to release your apps to WindowsXP.
>> Once Python is running your apps, the rest is peanuts.
> 
> Oh man, I was hoping to avoid that level of hassle.  
In contrary, that's what really makes fun. The registry is like a bomb in
your hand - it provides mighty power over the user!!!

> My app doesn't use any registry keys of its own, but I guess the 
> Python executable does, and that stuff presumably has to be updated 
> with every reinstall, 
Probably no. Since your update will certainly only affect py-files, there's
no reason to worry about the Python's registry activities.
The other thing is, that your update must know where to put the updated
files, and that information is usually kept in the registry.
But dealing with registry issues is very easy, even if you do it in Python,
if you install a release like ActivePython, which I would propose.
> and something is sure to eventually go wrong and corrupt 
> the registry, if this is anything like the Windows that I'm used to
> hearing about.  Sigh.  Just how bad is that under Windows XP?
Don't worry. That's very secure and fairly straigth-forward. 
However, you should be familiar with it. Make sure you have a XP machine
around and play with it. 
I'm manually modifying registry entries for almost a decade now, and I had
never crashed a system by doing so.

> I'm used to Windows 95 completely falling apart at the slightest
> error but I have the impression that XP is a bit more solid.
Are you sure that this had to do with registry modifications?
Take a Linux box, remove the contents of /etc, and then reboot.
What happens???
You're not stupid, are you? 
You wouldn't do that on Linux, so why should you spoil the registry?

> 
> Maybe I'll have to just tell them to install Python 2.4 from its
> distro MSI 
That's acceptable, I guess. Since that's rather easy.
> and then I can put together a distutils setup.py thingie 
> which they'd run separately.  
You're familiar with that? If so, yes, that's feasible.
But don't ask the user to launch setup.py.
If there's a GUI anyhow, why not launch it from there.
The user is certainly accustomed to the usage and you can easily make 
him/her cooperate by clicking an install button or select it from the
Help/About-Menu...

What about this, since you have VisualC++ around:

Write a simple C++ app, which launches the Python installer, then launches a
Python script which does all the other stuff?
Call it Setup.exe, place it on the top level of your CD, and there you
are...

Bernhard