makerplane / pyEfis

Electronic Flight Information System in Python
GNU General Public License v2.0
55 stars 31 forks source link

Default configuration file updates are not applied when upgrading pyefis or fixgateway #190

Closed e100 closed 2 months ago

e100 commented 2 months ago

The first time fixgateway or pyefis runs the default configuration files are copied into ~/makerplane/ To prevent overwriting user edited config files we do not copy a config file if the config file already exists.

With the screenbuilder include feature it would be nice to distribute user submitted include files with new versions. If a new version has updated default config files and the user has not modified them, we should replace them so that user can benefit from the improvements.

How could we easily identify what files have changed? The only idea I've has is to set a specific timestamp on the file when we copy them. Then check for that timestamp to decide if the file should be updated or not.

birkelbach commented 2 months ago

One of the things that I don't like about YAML is that there is no standard mechanism for including files. A lot of Linux utilities use includes from sub-directories to solve some of these problems. Then users could override what they want in included files and the distributed file could be replaced with new versions. This has to be specifically programmed in the application if using YAML.

Also, we could load the existing file into one dictionary, load the new file into a different one, somehow merge the changes and then write the result of the merge to the disk. This would destroy all of the comments in the files I guess so probably not optimal.

Using the difflib module to merge changes might be an option too. Then it's only an issue if there is a conflict, and I think then we keep the old user data and print a warning on the conflict. Otherwise it just happens invisibly. Since this is a text based solution, comments would be preserved in the old and the new.

Without doing all of that I think that just doing what you are suggesting with the timestamp would be more than fine. The users would simply have to look in the new files for the changes that they need to add to their old files to get the new features to work. Users that understand the system well enough to modify the configuration could be asked to do that I would think. Another way to detect the change would be to do a hash of the file and put that hash in a comment at the beginning of the file and then check it again on first run (or installation). If the file has been modified then print a warning, and leave it alone.

e100 commented 2 months ago

One of the things that I don't like about YAML is that there is no standard mechanism for including files.

I just created #192 that implements an include feature. I moved all of the screen configs into their own file and some redundant config options used on numerous screens were moved into a single file. It needs some recursion detection to prevent include loops, I'll work on that later today.

To keep the config files updated between version updates I created #191 Since a bug in this could cause data loss I'd like someone else to look this over before it is merged.

I'd like to add both of these features to fix gateway too