Windows distribution suggestions?

Discussion in 'Python' started by Paul Rubin, May 17, 2005.

  1. Paul Rubin

    Paul Rubin Guest

    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.
     
    Paul Rubin, May 17, 2005
    #1
    1. Advertising

  2. Paul Rubin wrote:

    >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.
     
    Timothy Smith, May 17, 2005
    #2
    1. Advertising

  3. Paul Rubin wrote:

    > 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
     
    Bernhard Holzmayer, May 17, 2005
    #3
  4. Paul Rubin

    Paul Rubin Guest

    Bernhard Holzmayer <> 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.
     
    Paul Rubin, May 17, 2005
    #4
  5. Paul Rubin wrote:

    >Bernhard Holzmayer <> 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
     
    Timothy Smith, May 17, 2005
    #5
  6. 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
     
    Bernhard Holzmayer, May 17, 2005
    #6
  7. On Tuesday 17 May 2005 09:35, Timothy Smith wrote:
    > 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.

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


    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.

    --
    Toby Dickenson
     
    Toby Dickenson, May 17, 2005
    #7
  8. Toby Dickenson wrote:

    >On Tuesday 17 May 2005 09:35, Timothy Smith wrote:
    >
    >
    >>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.
    >
    >
    >
    >>>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
    >>>
    >>>

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

    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.
     
    Timothy Smith, May 17, 2005
    #8
  9. Paul Rubin

    Paul Rubin Guest

    Bernhard Holzmayer <> writes:
    > > Hmm, ok, it looks like the paid version is around 500 USD....
    > > 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.


    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.

    > > The app works ok under Windows now.

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

    > > I don't want to need an admin account.

    > Nobody wants that. It just happens...


    Sigh. I guess it figures.

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


    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.

    > > I just put the app's files in C:/Program Files/appname...

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

    > >> Isn't Visual C++ still coming with a restricted version of InstallShield?
    > >> ...

    > 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! ;-)

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


    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.

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


    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, May 17, 2005
    #9
  10. Paul Rubin

    Paul Rubin Guest

    Toby Dickenson <> writes:
    > 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.

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


    I'll look at these and at INNO (mentioned in another post). Thanks
    again to everyone.
     
    Paul Rubin, May 17, 2005
    #10
  11. Paul Rubin

    Ivan Voras Guest

    Paul Rubin wrote:

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


    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.
     
    Ivan Voras, May 17, 2005
    #11
  12. Ivan Voras wrote:

    >Paul Rubin wrote:
    >
    >
    >
    >>>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.
    >>
    >>

    >
    >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
     
    Timothy Smith, May 17, 2005
    #12
  13. Paul Rubin

    Guest

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


    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
     
    , May 17, 2005
    #13
  14. Paul Rubin

    Serge Orlov Guest

    Timothy Smith wrote:
    > Ivan Voras wrote:
    >
    > >Paul Rubin wrote:
    > >
    > >
    > >
    > >>>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.
    > >>
    > >>

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


    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.
     
    Serge Orlov, May 17, 2005
    #14
  15. Paul Rubin

    rbt Guest

    Bernhard Holzmayer wrote:
    > Paul Rubin wrote:
    >
    >
    >>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


    Or, you could use a simple bat script... that's what I do.
     
    rbt, May 17, 2005
    #15
  16. On 2005-05-17, Paul Rubin <http> wrote:

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

    --
    Grant Edwards grante Yow! Did I SELL OUT yet??
    at
    visi.com
     
    Grant Edwards, May 17, 2005
    #16
  17. Paul Rubin wrote:
    > 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
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, May 17, 2005
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Oliver Denzel

    Re: C# windows app distribution thru web

    Oliver Denzel, Jul 7, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    1,128
    Oliver Denzel
    Jul 7, 2003
  2. Markus Stenzel

    Reverse Engineering of Windows Distribution

    Markus Stenzel, Jul 7, 2003, in forum: Python
    Replies:
    2
    Views:
    332
    Peter Hansen
    Jul 7, 2003
  3. Max Riedel
    Replies:
    0
    Views:
    350
    Max Riedel
    May 20, 2004
  4. Mark English

    Building Windows debug distribution

    Mark English, Dec 10, 2004, in forum: Python
    Replies:
    1
    Views:
    320
    Thomas Heller
    Dec 10, 2004
  5. Eric Lemings

    Windows No-Install Distribution?

    Eric Lemings, Aug 23, 2011, in forum: Python
    Replies:
    6
    Views:
    529
    Terry Reedy
    Aug 24, 2011
Loading...

Share This Page