Windows distribution suggestions?

[Paul Rubin]

As what must be penance for something or other, I'm needing to release
a Python app for use under Windows XP. Please be gentle with me since
I'm a Un*x weenie and the only thing I've had much practice with under
Windows is rebooting it.

My app contains three different programs (say alice.py, bob.py, and
carol.py) that need to be independently launchable, and a dozen or so
other .py files that get imported into those first three. What I'd
really really like is to make a single installer called (say)
"app.exe". Launching app.exe should completely install Python, unpack
all the necessary modules, and make three icons (alice, bob, carol) on
the desktop.

I know there's various ways of building Windows distros like that, but
am not sure what's currently preferred. Gordon McMillan's site
www.mcmillan-inc.com has had its domain expire (he really should renew
it before some squatter grabs it!) and the mirror that I've found
indicates that it was last updated for Python 2.3. I wrote my app
under 2.4 and while I don't think I depend heavily on any 2.4
features, I'd rather not have to downgrade just to make this exe
installer. There's also py2exe--is that as good?

Also, what's the preferred way of releasing updates? That is, let's
say I want to update my .py files and release a new version fairly
frequently--should I just make a new .exe every time? Would launching
the new one cleanly overwrite or uninstall the old one? Total
coolness would be a way to ship an "update.py" along with the app,
that syncs the app up to a Subversion repository, but that may be
asking a bit much.

I do have Visual C++ installed on the development machine, if that helps.

 

[Timothy Smith]

As what must be penance for something or other, I'm needing to release
a Python app for use under Windows XP. Please be gentle with me since
I'm a Un*x weenie and the only thing I've had much practice with under
Windows is rebooting it.

My app contains three different programs (say alice.py, bob.py, and
carol.py) that need to be independently launchable, and a dozen or so
other .py files that get imported into those first three. What I'd
really really like is to make a single installer called (say)
"app.exe". Launching app.exe should completely install Python, unpack
all the necessary modules, and make three icons (alice, bob, carol) on
the desktop.

I know there's various ways of building Windows distros like that, but
am not sure what's currently preferred. Gordon McMillan's site
www.mcmillan-inc.com has had its domain expire (he really should renew
it before some squatter grabs it!) and the mirror that I've found
indicates that it was last updated for Python 2.3. I wrote my app
under 2.4 and while I don't think I depend heavily on any 2.4
features, I'd rather not have to downgrade just to make this exe
installer. There's also py2exe--is that as good?

Also, what's the preferred way of releasing updates? That is, let's
say I want to update my .py files and release a new version fairly
frequently--should I just make a new .exe every time? Would launching
the new one cleanly overwrite or uninstall the old one? Total
coolness would be a way to ship an "update.py" along with the app,
that syncs the app up to a Subversion repository, but that may be
asking a bit much.

I do have Visual C++ installed on the development machine, if that helps

i have just gone through this process myself. if your sure your only
distributing the app to windows xp system, then it's perfectly possible
to update from an svn by using pysvn. pysvn doesn't currently work on
win9x clients.
py2exe - use it, it's damn good. it puts all your library's in a
library.zip file which can then use to update your app.
make a nice neat installer using NSIS, you can even use it to send
manual patches if you need to.
if you need any help making the pysvn or other parts work give me an
email i can help.

 

[Bernhard Holzmayer]

As what must be penance for something or other, I'm needing to release
a Python app for use under Windows XP. Please be gentle with me since
I'm a Un*x weenie and the only thing I've had much practice with under
Windows is rebooting it.

I can feel your unhappiness, and I share it. Hi Paul!
Here are some hints...

My app contains three different programs (say alice.py, bob.py, and
carol.py) that need to be independently launchable, and a dozen or so
other .py files that get imported into those first three. What I'd
really really like is to make a single installer called (say)
"app.exe". Launching app.exe should completely install Python, unpack
all the necessary modules, and make three icons (alice, bob, carol) on
the desktop.

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.

I know there's various ways of building Windows distros like that, but
am not sure what's currently preferred. Gordon McMillan's site
www.mcmillan-inc.com has had its domain expire (he really should renew
it before some squatter grabs it!) and the mirror that I've found
indicates that it was last updated for Python 2.3. I wrote my app
under 2.4 and while I don't think I depend heavily on any 2.4
features, I'd rather not have to downgrade just to make this exe
installer.

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.

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?

There's also py2exe--is that as good?

Depends on your application, if that is acceptable.
I have no experiences with that.

Also, what's the preferred way of releasing updates? That is, let's
say I want to update my .py files and release a new version fairly
frequently--should I just make a new .exe every time?

Providing an installation program called Setup.exe or Install.exe which does
everything (guided by a sequence of dialog boxes where the user presses
only the return key to get through the successful installation), is
state-of-the-art. Usually, one of the Wise or InstallShield installers, are
used. Or simple WinZip-Packages.

Would launching the new one cleanly overwrite or uninstall the old one?

If you've done it in the proper way with the proper tool, yes.

Total coolness would be a way to ship an "update.py" along with the app,
that syncs the app up to a Subversion repository, but that may be
asking a bit much.

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

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

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

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.

Bernhard

 

[Paul Rubin]

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.

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.

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.

 

[Timothy Smith]

Thanks! ;-)




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.




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.




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




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




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.




Hmm, that's another thing I'd have to code--maybe it's feasible. I'll
think about it.




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.




Hmm, that's really really interesting. How would I find out?




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.

mate dont bugger around with all that. py2exe will make you a windows
native exe to run. and for updates you just need to update it's
library.zip. use NSIS for the installer, it can do anything you want an
it's free.
it couldn't be more simple, shoot me an email if you need more

 

[Bernhard Holzmayer]

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

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

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

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

 

[Toby Dickenson]

mate dont bugger around with all that. py2exe will make you a windows
native exe to run. and for updates you just need to update it's
library.zip.

py2exe is working great for me too.

One tip: make sure your three top-level scripts are as empty as possible: just
import some other module and call a function. All your active code is then in
some library.zip shared between the three, and you need never change
alice.exe, bob.exe, and carol.exe

use NSIS for the installer, it can do anything you want an
it's free. it couldn't be more simple, shoot me an email if you
need more

Ive not used NSIS, but I have had good results from the free WiX tools, at
http://sourceforge.net/projects/wix/. Documentation is poor, but examples are
plenty.

 

[Timothy Smith]

py2exe is working great for me too.




One tip: make sure your three top-level scripts are as empty as possible: just
import some other module and call a function. All your active code is then in
some library.zip shared between the three, and you need never change
alice.exe, bob.exe, and carol.exe




Ive not used NSIS, but I have had good results from the free WiX tools, at
http://sourceforge.net/projects/wix/. Documentation is poor, but examples are
plenty.

another good one is Inno, although it's not as easy to use as NSIS. Inno
and NSIS can do anything a commercial installer can do, Inno especially.

 

[Paul Rubin]

1) Maybe you can start with the 30days demo license to find out.

Yes, I'd certainly do that first.

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.

Well, both would benefit, I think.

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.

Of course the customer wants this, but in reality it's going to have
to cost them, so I have to explain that and let them decide.

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.

I wonder if I'd be trading off 20 hours messing with py2exe or
whatever, against 20 hours of learning curve with Wise. Is Wise
really easy and fast to get started with? Well, I guess that's what
the evaluation version is to help find out ;-).

I'm concerned that it's going to be the same 20 hours either way (as
compared with just having them install python.msi separately), and 20
hours of development probably means a full week on the calendar
because of meetings, phone calls and all that usual stuff. This app
is a small component of a big project and spending an extra week on it
means the whole project takes longer, which is never a good thing.

Congratulations.

Ehh, no big deal, there's not much system dependency so far, and it
was developed under Windows (with IDLE even) from the beginning. It
may get more system dependent later.

Then you'll probably use ODBC, since the MySQL server will probably not be
run under Windows and on the same machine.

Hmm, at least at first I'd run MySQL on the same machine under Windows
(I know MySQL can run under Windows) but maybe that still needs ODBC.
Eventually it may have to talk to another DB like Oracle.

Nobody wants that. It just happens...

Sigh. I guess it figures.

Not that trivial! Plan enough time for testing.
And, if you install without sophisticated tool, reserve enough time for
troubleshooting and modifications...

Yeah, I really want to keep the installation stuff simple.

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.

Hmm, maybe not so easy, the customer may be using several different
Windows configurations in different places.

If the customer is able to run different versions at
the same time, keep one living copy of every possible version.

For now, I think I can say they have to track the current version.
It may be an issue in the future.

[self-updating feature built into the app]
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...

Well, it's something to keep in mind, but I'm hoping this stays simple.

Don't do that,... In other countries even Windows uses different
path names (e.g. here in Germany C:/Programme).

Good point!!! Yes, the customer will be running some non-English
Windows installations. Thanks for mentioning this, I'm sure I would
have otherwise found out the hard way.

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

Hmm, I think there's a Python function to read registry entries. I
better check the docs. Can I just use C:/Appname like the Python
installer does? If I have a way to launch the gui at all, I guess I
can have a configuration screen that lets the user change that
location.

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

I didn't see anything like that in the tools menu, but it's possible I
didn't install it. I think it's a 2-CD installation and I only
installed one of them (the guy at the office said that's the usual
way). It's Visual Studio 6 (the customer is on MSDN and supplied me
with the machine).

In contrary, that's what really makes fun. The registry is like a bomb in
your hand - it provides mighty power over the user!!!

Arrgghhh! ;-)

Don't worry. That's very secure and fairly straigth-forward.

Well, ok, I guess these fancy installers must have gotten better with
that. The usual disease I've seen is some installer wants to change
100 registry entries and something goes wrong halfway through, so only
50 of them get changed and the registry is then hopelessly
inconsistent. It's not like a real database with atomic commits and
rollback. The system still runs with the corrupt registry, but it
sort of degrades and crumbles and eventually you have to reinstall the
OS from scratch. I remember a common syndrome with Windows 95 was the
MSIE browser scroll bar grew to about 3x its usual width. Your system
was then within a few hours of becoming completely wedged.

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?

Well, it's uncommon for any Linux user app to go messing around with
system files, especially dozens of them haphazardly. Usually the app
puts its config info in its own file.

You're familiar with that? If so, yes, that's feasible.

I haven't done it before, but the docs look reasonable, so I'm
assuming I can figure it out.

But don't ask the user to launch setup.py.
If there's a GUI anyhow, why not launch it from there.

Hmm, how would the GUI get started? I don't like the idea of making
the user type "python setup.py install" from a dos prompt but just
double clicking on a setup.py (or install.py) icon doesn't seem too bad.

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

Hmmm, is that easy to do? Just fork a process, wait for it, and fork
another one? Maybe that's the simplest idea of all.

 

[Paul Rubin]

py2exe is working great for me too.

I should give it a try.

One tip: make sure your three top-level scripts are as empty as
possible: just import some other module and call a function. All
your active code is then in some library.zip shared between the
three, and you need never change alice.exe, bob.exe, and carol.exe

I think I understand what you're saying and it sounds like a very
good idea. Thanks.

Ive not used NSIS, but I have had good results from the free WiX
tools, at http://sourceforge.net/projects/wix/. Documentation is
poor, but examples are plenty.

I'll look at these and at INNO (mentioned in another post). Thanks
again to everyone.

 

[Ivan Voras]

I think I understand what you're saying and it sounds like a very
good idea. Thanks.

One thing about updating files - sorry if I'm stating general and
universal knowledge, but beware that on Windows you can't delete and/or
replace a file if it's opened by any process.

 

[Timothy Smith]

Paul Rubin wrote:




One thing about updating files - sorry if I'm stating general and
universal knowledge, but beware that on Windows you can't delete and/or
replace a file if it's opened by any process.

hence i found you must do this immediately after updating

sys.path_importer_cache.clear()
zipimport._zip_directory_cache.clear()

then unload your app

 

[dave.brueck]

One tip: make sure your three top-level scripts are as empty as

I think I understand what you're saying and it sounds like a very
good idea. Thanks.

To elaborate, this approach has worked well for me when I've needed to
release multiple .exe's together:

First make a "dispatching" module like this (call it run.py)

if __name__ == '__main__':
app = sys.argv[0].lower()
if app.find('alice') != -1:
import alice
alice.main()
elif app.find('bob') != -1:
import bob
bob.main()
etc...

Next, use py2exe to create an executable for run.py, and then copy
run.exe to alice.exe, bob.exe, and carol.exe (the resulting .exe's will
be very small). The reasoning behind this is that this way only one
copy of all the DLLs, Python std library, and so forth need to be
included in your release.

And to second everyone else's suggestions: NSIS and InnoSetup are
great, free, and powerful. They have all the features you need to
automatically copy your files to the "proper" location on disk, create
desktop icons, and create an uninstaller entry - you'll just write a
small installation script telling what features you'd like to take
advantage of, but they figure out all the details and combine your
application files into a standalone installer (your app.exe).

It'll take a little work to get this all straightened out the first
time, but after that you can have a single build/release script so it's
painless from then on.

And for updates: the least problematic approach is to just release the
whole thing each time. IIRC, InnoSetup (and probably NSIS) include a
feature where you can detect if your app is running when the user tries
to install an update and you can prompt the user to shut down first.
You'd need to use ctypes or pywin32 to make your app detectable that
way, but it's only 1 or 2 lines of code. But, lemme know if you want to
go the route of updating only portions of the app - I've gone that
route too but it takes more work and has its own set of problems; I
might be able to save you a few headaches.

-Dave

 

[Serge Orlov]

hence i found you must do this immediately after updating

sys.path_importer_cache.clear()
zipimport._zip_directory_cache.clear()

then unload your app

I don't think it's a good idea to update files of a running
application. It's better to copy the current version into
another directory and after successful update switch over
to the new version.

Dirs during update:
c:\program files\mysoftware\current
c:\program files\mysoftware\latest

post update
c:\program files\mysoftware\previous
c:\program files\mysoftware\current

The advantage of the approach of keeping the previous version
is that your customers can always switch back to the previous
version even if the network is not available or your update
server is down. It's like an undo button. If the users know that
they can easily downgrade, they will more willing to upgrade.

Serge.

 

[rbt]

Paul Rubin wrote:




I can feel your unhappiness, and I share it. Hi Paul!
Here are some hints...




Since your installer needs to run before Python is installed, you need
something else. Go to http://www.wisesolutions.com

Or, you could use a simple bat script... that's what I do.

 

[Grant Edwards]

As what must be penance for something or other, I'm needing to release
a Python app for use under Windows XP.

I'm a Unix guy who occasionally ships a Python app for Win32,
and I always recommend py2exe and inno setup:

py2exe http://starship.python.net/crew/theller/py2exe/
inno setup http://www.jrsoftware.org/isinfo.php

Inno setup is as good as any other installer, and it's free.

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

My app contains three different programs (say alice.py, bob.py, and
carol.py) that need to be independently launchable, and a dozen or so
other .py files that get imported into those first three. What I'd
really really like is to make a single installer called (say)
"app.exe". Launching app.exe should completely install Python, unpack
all the necessary modules, and make three icons (alice, bob, carol) on
the desktop.

It's not clear to me whether you really want to install a full version
of Python on the target machine; py2exe and Co. incorporate the minimum
subset of Python and ship this each time you make a distribution. So
Python is not installed on the target machine on its own.

In principle, it is possible to create an installer that first installs
Python (with entries in the start menu and all), and then installs your
own application.

If this is what you want, I would personally go with .msi instead of
using .exe. It can do "nested installs", where you can launch
the standard python-2.4.msi from your own MSI file. It also supports
"patch updates", where you replace the files that have changed on
the target machine, through a patch MSI.

The tricky part is to find a good authoring tool for .msi. I would
personally use my own Python library, but that requires to dig
into the MSI details.

Regards,
Martin