Through the years, I've looked at lots of different configuration schemes, but haven't found any I like better.
The big advantage of the present system is that all the state is held in a single place: weewx.conf. That makes support easy: just post the file. It also makes it easy to run more than one instance of weewx: just point each daemon to an appropriate config file. Upgrade merges are easy: just upgrade a single file, usually through a simple configobj merge. By contrast, the weewx.d approach spreads state over multiple places. I have also looked at "drop in" architectures, similar to Apache's "sites-available" approach. To enable a service, you would symlink its python file from "services-available" to "services-enabled". I can't remember exactly why I abandoned the idea, but it came down to python not liking symbolic links. It also makes remote debugging tough. No perfect system, but this one has served us well. -tk On Thu, Dec 26, 2019 at 10:06 PM Ben Cotton <[email protected]> wrote: > On Mon, Dec 23, 2019 at 3:06 PM vince <[email protected]> wrote: > > > > Ben - I've asked for changes in the last few years (and Matthew+Tom have > made many) along the lines of making it a bit easier to do weewx with > DevOps mindset. What in particular are you battling ? > > > I may be battling my own tendency to over-engineer more than anything. > I'm really looking at a hypothetical problem than a real one. What > I've done for now is set up a playbook to install today's current > version. As infrequently as I reinstall this machine (before > yesterday, I last did an install probably 10-ish years ago), that's a > fine approach. I can always update the playbook with a post-upgrade > config file as needed. > > But in my ideal scenario, I'd like to see something like the way > Apache httpd and other daemons parse configs. So there would be > /etc/weewx/weewx.conf that would have the default settings and then I > could overwrite things as needed in /etc/weewx/weewx.local and/or > /etc/weewx/conf.d/*. > > Another approach would be, at least on RPM-based systems, for the RPM > to just write an .rpmnew file and leave the existing config in place. > I'm not sure how much effort that would take to keep weewx happy—I > haven't looked in detail to see what sort of things get changed in the > config file between releases. Along this line, I'd briefly looked at > packaging weewx in the Fedora repos (or at least a COPR build), but > the amount of shell script in the RPM spec file changed my mind. :-) > > -- > You received this message because you are subscribed to the Google Groups > "weewx-user" 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-user/CAJox116eGQWipneTqwW5jQHamoqNvj-X%2Bk8u9kgJE0OHpZA6_Q%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "weewx-user" 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-user/CAPq0zEBXmgpGGvgAcddmD2%2BzY1dCtn7rtZ-3wVbPWK-sYNkh-A%40mail.gmail.com.
