(apologies if a previous draft reply made it out - Safari got me again in the post message gui)
On Tuesday, November 8, 2022 at 4:15:02 AM UTC-8 matthew wall wrote: > On Tuesday, November 8, 2022 at 12:10:22 AM UTC-5 [email protected] > wrote: > >> >> - could a wee_ctl command be able to run versus a TBD format data >> file of its own telling it what to do ? >> >> not sure what you mean by this > > In days of old most software used autoconfig/metaconfig and you ran "sh Configure.sh" to generate a datafile with all the keyword=value pairs to configure the software during a make by writing an intermediate data file out. This essentially was nice and idempotent, as subsequent configuring used that to preseed the answers it would ask you again. > in the case of a docker (or salt or ansible) installation, i would create > the conf file *before* the installation, then just drop that config file > into the 'create-station' part. i do that right now on systems i manage > with salt where i run weewx. i use a bare-bones config file (with no > comments, and only the sections that *must* have parameters specified (in > older weewx, not specifying values would cause weewxd to die, even if you > just wanted defaults). so effectively i 'create-station' myself. > > yup - a bit of a chicken-and-egg problem for updates where weewx.conf content changed (all updates do this). You have to know experimentally get a file before knowing what to do. I tend to build a throwaway vagrant VM and diff the weewx.conf files to see what changed. A little painful. But yes. Agree. I did have a possibly crazy idea though - what if you built weewx.conf at 'runtime' based on multiple mostly-optional config definitions.... Here's an example that illustrates things using the filesystem as an example. Anything with [ ] is a directory, [[ ]] is a subdirectory therein, [[[ ]]] one more level deep, and so on. Anything with an = sign would have the keyword be the filename and the value be the content of the file. [Station] latitude = 12.345 would be a file ./Station/latitude with content 12.345 Similarly: [StdRESTful] [[StationRegistry]] register_this_station = true would be a file ./StdRESTful/StationRegistry/register_this_station with content true And: [StdReport] [[Belchertown]] [[[Labels]]] [[[[Generic]]]] home_page_header = Current Weather Conditions would be a file ./StdReport/Belchertown/Labels/Generic/home_page_header with content 'Current Weather Conditions' So to define a keyword=value pair, you'd 'mkdir -p' the tree and create the file with content being the value on the right side of the = sign. To disable something, delete the file. If you have items with values that are comma-delimited, split them up one line per item in the element's data file's content perhaps. (disclaimer - this breaks if you have a keyword with a / in it such as a MQTT topic like vp2/loop, but lets ignore that tidbit for now) At runtime, assemble an aggregate weewx.conf you'd walk the tree, put the right number of [ ] around the directory names, create the variable names in the right places based on their file's depth in the tree, and put the values on the right side of the = based on the content of those files. In short, build an aggregate weewx.conf at 'runtime' based on pieces of the puzzle that are easy to add/delete/change either manually or via tooling. That would get you a drop-in kind of scenario where you'd have a lot of very simple one-line files in a hierarchy. The simplest possible setup would have a data file tree that would be pretty simple based on the questions asked today - location/name/lat/lon/driver and a few other things. Complicated setups would be pretty much unbounded. Guess I really like drop-in componentization, being a somewhat lazy coder as well... -- 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 on the web visit https://groups.google.com/d/msgid/weewx-development/40f33957-4822-44ad-9b15-985773dc4644n%40googlegroups.com.
