I have a customer who has many (Windows) computers on which Python and related packages must be installed/updated on regular bases. One of their concerns is wininst based packages, which do not allow unattended installation. Newer and greater MSI helps, but there are legacy packages. Can you give me opinion: 1) Why pywin32 (Mark Hammond) is continued to be distributed in wininst form? 2) If one prepares MSI package, are there foreseeable snags to distribute it in 2.4 environment? 3) I offered to consider development of wininst to msi (ready package) converter. Is it stupid suggestion, or is it feasable (and easier than silencing of wininst)? Would there be interest for such converter (my customer is willing to contribute to Python project)? Thank you!
I have a customer who has many (Windows) computers on which Python and related packages must be installed/updated on regular bases.
One of their concerns is wininst based packages, which do not allow unattended installation. Newer and greater MSI helps, but there are legacy packages.
Can you give me opinion:
1) Why pywin32 (Mark Hammond) is continued to be distributed in wininst form?
The bdist_msi packager is missing some features of bdist_wininst; things like adding of shortcuts, a "post_install" script that is capable of recording files to be uninstalled, communication of setup options to the install scripts, etc.
2) If one prepares MSI package, are there foreseeable snags to distribute it in 2.4 environment?
See above - although I am currently working on bdist_msi so I can package an x64 version - this is likely to make it easier for me to use bdist_msi - although at this stage I'm not sure about moving all releases to bdist_wininst.
3) I offered to consider development of wininst to msi (ready package) converter.
What would such a converter do? For simple packages with an existing distutils setup script, you simply use a different command-line to create an MSI instead of an EXE, so a converter seems unnecessary. A converter could not address the issues I listed above either (ie, functionality available to the post-install script)
Is it stupid suggestion, or is it feasable (and easier than silencing of wininst)? Would there be interest for such converter (my customer is willing to contribute to Python project)?
Other alternatives include: * Open the .exe installer as a .zip file and simply copy the files into the target * Enhance bdist_wininst such that it supports args for silent install, then ask people maintaining the packages to use this new executable. I'd have no problem doing that. Cheers, Mark
Thank you very much for clarifications.
3) I offered to consider development of wininst to msi (ready package) converter.
What would such a converter do? For simple packages with an existing distutils setup script, you simply use a different command-line to create an MSI instead of an EXE, so a converter seems unnecessary. A converter could not address the issues I listed above either (ie, functionality available to the post-install script)
The proposed converter would handle third-party modules, which came in as ready-to-use .exe files. An idea to read distribution.exe (as zip) and write as msi distribution, which would be installed than on all computers in need. That was based on presumption that wininst is superseded by msi, which is clearly incorrect, as you've shown. Therefore conversion would allow to use 'legacy' distributions (without using wininst). Can you comment on one more idea: instead of modifying bdist_wininst, to modify wininst.exe to support silent installation. This change could be obviously submitted as well, and as an interim solution simple replacement of stub (in distribution.exe) could be used. Vadim
That was based on presumption that wininst is superseded by msi, which is clearly incorrect, as you've shown.
Well, all I really meant to say was that bdist_msi doesn't (yet) have all the features of bdist_wininst - but bdist_msi does appear to be the "future" (ie, there is not much interest on this list towards keeping bdist_wininst alive going forward)
Can you comment on one more idea: instead of modifying bdist_wininst, to modify wininst.exe to support silent installation. This change could be obviously submitted as well, and as an interim solution simple replacement of stub (in distribution.exe) could be used.
Yes, that is what I meant - modify the stub executable bdist_wininst uses to perform its magic. However, keep in mind the comments above regarding the (lack of) future for bdist_wininst - eg, even with this modification, its not clear it will ever be suitable for installing 64bit Python extensions. So while it may be suitable for your specific problem, you may need to revise things when x64 moves into your radar, for example. Mark
Thank you. It was my impression also. I guess, I need to do more research regarding available options. Vadim
participants (2)
-
Mark Hammond
-
vadim suvorov