[Python-Dev] Install-on-first-use vs. optional extensions (original) (raw)

Tim Peters tim.peters at gmail.com
Wed Sep 8 21:24:49 CEST 2004

[Martin v. Löwis]

I recently looked into properly implementing the "Register Extensions" feature in the installer; in 2.4a3, not selecting that doesn't really work. The problem is that MSI only supports installing either both the "extension server" (the .exe) and the extension, or neither. So you can chose not to install word.exe, and it won't install the .doc extension; if you install word.exe, it will associate .doc with it.

For Python, this leaves us with three options: 1. Don't make registration of extensions optional; always associate .py, .pyc, .pyw, .pyo.

-1. If we do that, I'll never install an alpha or beta again <0.5 wink>.

2. Don't support installation-on-demand for extensions. This means to not use the MSI extension machinery at all, but to directly write the registry keys that build the extension. Installing these keys can then be made optional.

+1. I may or may not want to change/create .py (etc) extensions. I never before heard of the concept of "install-on-demand for extensions", and I don't think I want to.

3. Provide another binary that is the "extension server", and install that independently of python.exe, and pythonw.exe. In CVS, I have implemented this approach to see whether it works (it does), and called this binary "launcher.exe". It is a Windows app which supports a -console argument which also makes it a console app. This is the the binary that gets associated with all four extensions, for the "open" verb.

This is soooo convoluted compared to what it's trying to achieve: write the registry entries, or don't, end of story. It would be nicest if the code to fiddle the registry were materialized as a .reg file. Then (later, and manually) switching among multiple installed Pythons would be easy.

More information about the Python-Dev mailing list