[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4