Windows distribution suggestions?

[Timothy Smith]

Paul Rubin wrote:

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