It is a very long time since I installed weewx from scratch, so I need
to (and will) do so on a spare machine, so that I can see how
installation/initial configuration now works, but things still not
infrequently do need to be changed later.
I understand where you are coming from, but I think that (at least one
of the places) where we differ is that I think of the config file as
part of the human interface and you think of it as part of the core
program. While weather geeks may, as a rule, be a bit more techy and
computer literate than the average person in the street, they are not
necessarily much more so. If one wants to configure weewx beyond the
bare minimum, one has to get 'down and dirty' with weewx.conf, so you
cannot assume that everyone who does so is familiar with config files.
One approach to this would be to 'pre-parse' the config file whenever
weewx is run after a config change and abort with a human language (i.e.
not a python exception cascade!) warning if something doesn't make
sense. Another, and my preference, since I think it is easier, is to
anticipate likely user syntax errors and try to do what the user wanted,
when it is clear what this is.
In another life, I have written a lot of user interface code and Help
text for non-techy users of database software. In many ways, that is
easier, since you can catch some user errors faster and earlier, but
much of the thinking is similar. In particular, in reading
documentation/config file comments (if they do!), users frequently see
what they expect to see, rather than what is there.
On 4/1/2023 11:55 AM, matthew wall wrote:
peter,
perhaps the place to do this is in the prompt(s), not the parser; keep the
config grammar strict, and make the human interface lenient.
if a person modifies the config file directly, s/he should understand the
implications, there should be appropriate comments in any sample config and/or
documentation, and whatever parses/uses the config should provide ample
feedback (stdout and/or log) when there are problems.
if that is the strategy, then the place to look in the V5 codebase is
'config_altitude' in bin/weecfg/station_config.py
m
On 1 Apr 2023, at 09:52, 'Peter Fletcher' via weewx-development
<[email protected]> wrote:
It really is a 'talking to humans' issue, not, in any real sense, a bug in the
code. weewx.conf is about the only place that a (non-developer) human will be
'talking' to weewx, so it seems reasonable to take a few extra steps to make
the 'conversation' there more natural for the human. I am still running V4.10,
and haven't really looked at V5.x, but if you would like to point me to the
code in V5 that scans and parses weewx.conf, I will take a stab at it.
On 4/1/2023 8:25 AM, Tom Keffer wrote:
Internally, weewx traffics in ValueTuples, which is a value along with a measurement unit. SI Units are things like "second",
"meter", "kilogram," etc. not "seconds", "meters", and "kilograms". See NIST. So,
internally, that's what we want.
Now when we talk with humans, we may want to use plurality if there is likely
to be more than one, but that requires a mapping to and from the singular value
used internally. WeeWX already has some software that does the transition from
internal (SI) units to language, so I suppose we could write something to go
the other way.
It all seems unnecessarily complicated, but if someone wants to write a PR, I'm
willing to take a look.
-tk
--
Peter R. Fletcher <[email protected]>
Home Page - https://pfletch.fletchers-uk.com
--
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/7300b237-f7f4-4ec1-d768-32d1466e5c71%40fletchers-uk.com.
