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.
