Windows distribution suggestions?

[Paul Rubin]

Bernhard Holzmayer <Holzmayer.Bernhard at deadspam.com> writes:
> I can feel your unhappiness, and I share it. Hi Paul!
> Here are some hints...

Thanks!  ;-)

> 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.

> You'll have to test your application on Windows, in any case. 
> I've built lots of applications which run in both worlds (Linux/Windows).
> Usually this works, but occasionally you'll have to deal with strange
> things. One is, if you use ODBC. There's good chance that you'll have to
> deal with access restrictions in the %SYSTEM% directory, unless you require
> an administrator's account for your application.

The app works ok under Windows now.  I don't use ODBC.  I might need
some database connectivity later and will probably use MySQL.  I don't
want to need an admin account.  Right now the app just has a Tkinter
gui, reads and writes a few files and talks to some sockets.  I might
need to add some C extensions later but those should be pretty portable.

> If you test your app on a Windows machine, you can easily install
> Python 2.3 and Python 2.4 on the same machine without
> conflicts. Just try out, if your app works with either. If it works
> with both, why not use 2.3?

I guess I could do that.  I believe I make some minor use of 2.4 features
but I can probably retrofit those things.

> > There's also py2exe--is that as good? 
> Depends on your application, if that is acceptable. 
> I have no experiences with that.

Me neither.  I was hoping to find out its good and bad points as compared
with alternatives.

> Who are your customer's (the recipients of your program releases)?
> Usually, you cannot rely that they have online access to your repository.
> Then, they are potentionally interested in security issues and/or stability
> of the program. I'd not like a program which is said to require frequent
> updates - I'd guess that there's not much quality inside...

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 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.

> If you have command line apps, why not provide an additional update.py 
> and then, if you provide updates, just install them using your installed
> update.py. The only thing: How do you keep track of path/desktop/file
> information and how do you deal with user rights etc.?
> Are you aware of how this is done under WindowsXP? It's quite different from
> older Windows platforms! Therefore it might be easier, to leave this to
> professional installation tools.

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.

> > 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?  

> 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.  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, 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?  
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.

Maybe I'll have to just tell them to install Python 2.4 from its
distro MSI and then I can put together a distutils setup.py thingie
which they'd run separately.  That might be acceptable to the customer
if it saves a lot of development effort and prevents user hassles when
things go wrong.  It would sure be nice to have one of those slick
one-click installers though.