EDCD
Store EDMC's settings in a file rather then the Windows Registry.
Is there any chance of EDMC not storing its settings especially the data for plugins like DistanceCalc in the Registry but a local file? I'd like to keep these settings when I reinstall my system after every major release for Windows 10 and be able to synchronizing them between several computers.
This is obviously possible, but you do know you can use 'regedit' to export parts of your registry and then later re-import them just by running the resultant file ?
What's stopping a plugin from implementing its own way of saving settings/data ?
What's the best file location for such settings? I'm thinking %LOCALAPPDATA%\EDMarketConnector\. It's already where EDMC stores some data (and where the user plugins should be installed).
What file format? As the app is in python it makes sense to use YAML (rather than INI or JSON).
And then there's writing something to sanely migrate the data. Easy enough for the core code settings, but plugin authors would really have to take care of their own settings/data.
I know, that entries from the registry can be exported and imported. However, I don't know of way to automate this with the Nextcloud client.
What plugins can or cannot do is beyond my not existing skills in programming.
%LocalAppData%\EDMarketConnector\ is fine, as I can either synchronize it manually or redirect it with a junction point.
The format doesn't matter in my case, as I plan to synchronize the file itself with Nextcloud.
I didn't know, that the plugin author decides where its setting are stored. I always assumed, that they "just tell" EDMC to handle it.
Take a look at reg export /? for shell/command based registry export.
Plugins can decide for themself if they want to use the provided configuration handling of EDMC or their own version. My plugins do use the EDMC config.
WinSparkle (the used installer) still needs the registry entries on windows.
Again, I know that registry entries can be exported and imported and that this can be done with batch files and PowerShell scripts. And again, I don't know how this can be utilized to synchronize these entries with Nextcloud.
What file format? As the app is in python it makes sense to use YAML (rather than INI or JSON).
YAML has issues that I'd rather we didn't end up having to go down. Such as insane string treatment (and 60-odd subtly different ways to format those strings), alongside security issues, and valid code that can break python (looking at you, maps with maps as keys).
I'd suggest TOML as an option, there's a preexisting API that is marked as prod ready and is used in a number of places. The config is INI-like while having a robust standard.
See also https://github.com/EDCD/EDMarketConnector/projects/9#card-51607246
Refocusing this, it might make more sense to have an "export" and "import" for the config, where the config can be fully written to a file and then read in. Of course, this opens up on Windows a lot of potential registry shenanigans, so we'd need to do this safely.
Theoretically, we can use existing parts of the Windows config to do this without opening up more modifications to the registry than we need to.
I'd envision Export potentially being something along the lines of winreg OpenKey and doing a loop for values, saving to disk. Probably would want to not grab some sensitive keys like FDEVAPI. Should be pretty simple imo, and could be set so that no user input is possible to prevent malicious use.
After that, on an import, we could validate the file format and then do a config.set (which already exists). This would serve the purpose of allowing import and export of our config file, without touching the registry more than we need to.
https://github.com/EDCD/EDMarketConnector/blob/bb87fced89b0c1d18381a813f1f8a9c5f7dea66a/config/windows.py#L157-L181
Benefits of this, it would use (mostly) existing processes and systems (and wouldn't need to completely redo our config).
On the other hand, we could completely chuck the current config in the bin to get away from Windows registry and move things to a file... but given that system is already in place and mature are the benefits worth the trade-offs. I suppose theoretical benefits are being able to unify config across Windows and Linux, but there's lots of niche edge cases to consider.
Based on discussions with some users, decided to go with a brand-new config system that is (ideally) unified across Linux and Windows.
See PR #2527