[Python-Dev] Install-on-first-use vs. optional extensions
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