wview structured its configuration into multiple files. I was never very keen on the idea. You never knew where to look, and there was a constant treasure hunt with Michael trying to find the key option. Later, he started adding configuration information to a sqlite database, and that made things even worse.
When I started on WeeWX, one of the first decisions I made was that everything would go into one file, no matter how big. This way, all the state is in one place; everything you need to know about a user's configuration is in that file. For the same reason, there are no environment variables and no command line options. Yes, the file is large, but it is well-structured. I think it has stood the test of time. -tk On Thu, Feb 26, 2026 at 11:26 AM Vince Skahan <[email protected]> wrote: > One more wild set of questions..... > > In the other thread Tom mentioned that nowadays he'd look at TOML format > since it's no longer 2008. > > If we had a clean sheet of paper today what would it look like ? > > Would it look more like a modern unix system's setup ? > > - perhaps use TOML format as Tom mentioned or JSON or YAML - doesn't > really matter perhaps > - but don't simply redo a monolithic weewx.conf into a different format > - instead also think ala-carte componetization. Add/delete 'files' to > a conf.d directory like modern apps do > > Think about how the mosquitto broker is configured. One toplevel > mosquitto.conf file that reads a conf.d directory containing 'components' > it adds up as it starts. Similarly how nginx has the concept of > 'sites-enabled' where you can pick which of the 'sites-available' you want > to start. > > So just wildly thinking about a what-if for discussion purposes - using > nginx's way as an example: > > Toplevel config with defaults (?) > > - /etc/weewx/weewx.conf > > All ala-carte added and selectable items: > > - /etc/weewx/conf.d/components-available/mything.conf > > Out of that list, the set of what is enabled: > > - /etc/weewx/conf.d/components-enabled/mything.conf - symlink to > 'components-available' file or a copy of it ala nginx > > So run this to see today's tree structure: > > - grep "\[" weewx.conf > > What do you see ? > > - add-ons can add to lines within a [[ ]] block > - add-ons can add to lines within a [ ] block > - add-ons can add things to things currently at the toplevel above any > [ ] nesting > - anything goes basically - that's not necessarily good or bad of > course... > > > Just thinking about a few examples that make different modifications to > weewx.conf currently.... > > weewx-mqtt: > > - adds a [StdRESTful] [[MQTT]] block > - adds to the list of restful_services in [Engine] [[Services]] > > or MQTTSubscribe: > > - adds to the list of data_services in [Engine] [[Services]] > - adds a 'toplevel' [MQTTSubscribeService] block > > or Belchertown skin: > > - adds a [[Belchertown]] block to [StdReport] > - but adds its services into its skin.conf > > of the GW1000 driver: > > - adds a toplevel [GW1000] driver block like every other driver does > - adds a zillion items under [Accumulator] > > > So given add-ons can (and do) add to items at basically any level in the > namespace, is that good long term ? > > If we go with TOML for discussion purposes, configuring weewx-mqtt would > look like: > > [StdRESTful.MQTT] > enable = true > client_id = vp2 > server_url = mqtt://192.168.1.69:1883/ > append_units_label = false > topic = vp2 > log_success = false > log_failure = true > [Engine.Services] > restful_services = user.mqtt.MQTT > > Hopefully this 'adds' to the list of assembled restful_services that run > at a system level. > > I don't know. Does TOML help today's as-is ? Does componetizing ? I > really don't know. > Ultimately the user has to edit 'something' eventually I guess... > > On Thursday, February 26, 2026 at 9:53:58 AM UTC-8 Vince Skahan wrote: > >> Not a big deal - I was mainly asking to see if more than a few sometimes >> thought this was an itch worth scratching. >> >> In my case I was trying to script ala-carte bill-of-materials based >> builds using ansible. The basic problem that weewx lets a third party >> developer put anything they want into any location within the namespace. >> So there might be multiple 'debug = 0' or 'log_success = true/false' >> items in weewx.conf and it is not possible using ansible nor puppet nor any >> other tool I've found to let you automate setting '*just THAT one*' to a >> desired value. >> >> Maybe there isn't a good solution for something so extensible. I was >> just asking if others have thoughts.... >> >> On Thursday, February 26, 2026 at 6:32:54 AM UTC-8 Greg Troxel wrote: >> >>> Vince Skahan <[email protected]> writes: >>> >>> > Would some kind of utility to permit simple edits of 'any' item in >>> > weewx.conf be of any value to think about ? >>> > >>> > Something like "weectl edit config" or the like (for discussion >>> purposes) ? >>> > >>> > # edit weewx.conf >>> > weectl edit config --set "[StdRestful][[MQTT]]" --key "log_success" >>> --value >>> > "true" >>> >>> Perhaps, but this is something that really should be implemented in >>> configobj first -- is that already there? >>> >>> Can configobj read a file into some pythonic data structure, let you >>> change it, and then write it, and have that result in no changes (or >>> formatting regularization that is stable), in particular preserving >>> comments? Is the implementation just parsing the headings and >>> assigning a variable, after read and before write? >>> >>> (I presonally would prefer >>> --set /StdRestful/MQTT/log_success=true >>> but I realize that's turning windows ini back into unix paths and >>> everybody else wouldn't like that!) >>> >>> > I know simply telling them 'edit the file dude' of course works, but >>> it >>> > might be helpful for scriptability if there was a way to automate >>> > add/edit/comment/uncomment things programmatically. The use of >>> configobj >>> > makes this really hard to do without some wrapper utility being cooked >>> up. >>> > >>> > I did think about some alternate ways: >>> > >>> > - convert the .conf in configobj format to JSON or YAML >>> > - edit thataway >>> > - convert it back to configobj format >>> > >>> > But that would be ugly at best and likely would lose any comments from >>> the >>> > .conf file. >>> >>> configobj talks about round trip: >>> >>> ConfigObj is a simple but powerful config file reader and writer: an >>> ini file round tripper. Its main feature is that it is very easy to >>> use, with a straightforward programmer’s interface and a simple syntax >>> for config files. >>> >>> * All comments in the file are preserved >>> >>> * The order of keys/sections is preserved >>> >>> so in theory this should work. >>> >>> It should be easy enough to test with >>> >>> read weewx.conf to python data structure >>> write that to weewx.conf.roundtrip >>> >>> and diff. >>> >>> >>> >>> I remember problems with earlier config updates (maybe 4 years ago) >>> where the generated config would have some odd whitespace that was >>> different from the standard config file. But I think that's no longer >>> the case. >>> >>> -- > You received this message because you are subscribed to the Google Groups > "weewx-development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/weewx-development/9a950eaf-766c-47d5-8f29-4d17bb8e15can%40googlegroups.com > <https://groups.google.com/d/msgid/weewx-development/9a950eaf-766c-47d5-8f29-4d17bb8e15can%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "weewx-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/weewx-development/CAPq0zECNW96CcPrtrynSHSmQGJj3%3DMo4X2%2Bn9Xm9exWnVg2RdQ%40mail.gmail.com.
