[Python-Dev] Install-on-first-use vs. optional extensions

[Tim Peters]

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