Vince Skahan <[email protected]> writes:

>    - in the new vision's future, would we have one weewx.conf or a bunch of 
>    them that are either additive or with some superseding rules.  Again, 
>    thinking about how puppet and splunk do things, which can get really 
>    confusing in figuring out why it did what it did.

Sort of related, I have encountered multiple styles of reading config
files and multiple cultures of config file contents over the years, and
strongly prefer configuring only non-default behavior without massive
commented-out content.

1) Ignoring comments and commented-out config, some programs seem to need
large config files where many things are set.  Others have defaults for
most configurable things, and one adds config lines only when setting
something to a non-default value.   This results in smaller config
files that are easier to understand, and it results in easier upgrades
because there is no need to merge changes to defaults and to comments
that explain them, because those things are in the documentation and not
in the user's config file.

2) Related, even for programs that only need non-default config, there are
(oversimplifying) two styles of config file templates for users:

  A) a file that is a full example of everything that has, for each thing,
  and explanatory comment and a commented-out line that configures the
  default.

  B) a file that has, not commented-out, and not trying to be
  documentation, config lines for things that must be set

I think that type-A examples are useful, but that they should truly be
examples and no one should encourage people to copy them to weewx.conf
and then edit them for use.


3) Thoughts about defaults:  Looking over the diff from my weewx.conf to
the sources, I find:

  log_success set to False

  location/lat/lon/altitude

  station_type (Vantage)
    A vast amount of stuFf that I copied at some point and should not
    have.  It needs:
      serial port path and baud rate
      model_type (belongs near 1st, I think)

    It does not need
      tcp port, tcp send delay (but others would, *instead* of port/baud)

    It has, but could/should be default for most
      loop_request (LOOP1)
      iss #1
      timeout 4
      wait_before_retry
      max_tries

    It has, oddly
      driver=
    and i say odd because that's at end, and it points out that the
    section has a name, but really this driver= is the actual config and
    the things that came before are data fortthat config engine.

  mqtt section
    [an extension, but other than retain=False and
    aggregation=aggregate, my lines are mostly real config that can't be
    default, setting the broker URL and topic, setting pressures to hPa,
    and putting %.1f on dewpoint.]

  skin config
    lots of stuff, that I changed.  Makes we wonder if main config and
    skin config should be separate files, but probably doesn't matter

  setting group_pressure to hPa.

  getting rid of the vast restful_services and setting to just mqtt.   I
  don't like all these random services being enabled even if they decide
  they aren't configured and don't do anything.  default should be none.


Overall, the stock config is 595 lines.  "diff -U0" of mine is 162, and
the + lines (lines in mine not in stock, so ignoring removed lines and
ignoring diff metadata) is 134.

Having analzyed I find that weewx is not in the massive-commented-out
camp, but there's still a fair bit.

In comparison, to pick an example,  /usr/pkg/etc/sudo_logsrvd.conf 
has 251 lines and configures exactly nothing.  Maybe that's a packaging
bug to install it, maybe it's an upstream culture bug.

clamav is even bigger.  786 lines of clamd.conf, yet:

  $ egrep -v '^$' /usr/pkg/etc/clamd.conf | egrep -v '^#'
  PidFile /var/clamav/clamd.pid
  LocalSocket /var/clamav/clamd.sock

and even those ought to be built-in from the var path at configure time,
and probably are.

-- 
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/rmizgd1k4o1.fsf%40s1.lexort.com.

Attachment: signature.asc
Description: PGP signature

Reply via email to