The outcome of our discussion in the ticket was this:
The SQlite DB (tinypilot.db) should be the default place for new settings, whereas the YAML file (settings.yml) should only be used in exceptional cases, and obviously for legacy reasons.
We favor having a single storage solution over a dual approach, as that simplifies future decision-making, and eliminates potential migration burden between the two storage formats.
This PR adds a comment in settings.py, marking its usage as quasi-deprecated. It also adds some historical context, references the SQlite DB as default storage, and lists sample exceptional cases.
I realized that we probably don’t need to add any documentation to the SQlite DB, since there is not really an alternative to it any longer. So by deprecating settings.yml, the SQlite DB is the only storage option anyway, and there shouldn’t be any ambiguity left. Contrary to my initial proposal, I also don’t think we should move settings.py up to the app package, as that might mistakenly promote its usage.
Resolves https://github.com/tiny-pilot/tinypilot/issues/1524.
The outcome of our discussion in the ticket was this:
tinypilot.db) should be the default place for new settings, whereas the YAML file (settings.yml) should only be used in exceptional cases, and obviously for legacy reasons.settings.ymlseparately.This PR adds a comment in
settings.py, marking its usage as quasi-deprecated. It also adds some historical context, references the SQlite DB as default storage, and lists sample exceptional cases.I realized that we probably don’t need to add any documentation to the SQlite DB, since there is not really an alternative to it any longer. So by deprecating
settings.yml, the SQlite DB is the only storage option anyway, and there shouldn’t be any ambiguity left. Contrary to my initial proposal, I also don’t think we should movesettings.pyup to theapppackage, as that might mistakenly promote its usage.