Not a bug, really - V5.0.0.a25

Skip to first unread message

Ernest Jillson

Mar 26, 2023, 9:14:53 PM3/26/23
to weewx-development
I decided to give this a whirl on a development pi zero I have. I made a typo in the setup program when selecting my elevation and units. I put "feet" instead of "foot". It didn't end well :).
It might be worth either allowing foot/feet and/or mooter/meter (ok, I made that up. meter/meters) so dumbos like me can succeed :).
Would it be possible to check the input and give an error message and a chance to retry instead of just failing? 
Again, it was my dumbassery that lead to the issue. Just thinking ahead for others that could potentially make the same mistake that I did.  Here is the error message:
Unpacking python3-weewx (5.0.0a25-1) ...
Setting up python3-usb (1.0.2-2) ...
Setting up python3-cheetah (3.2.6-1+b1) ...
Setting up python3-configobj (5.0.6-4) ...
Setting up python3-weewx (5.0.0a25-1) ...
The configuration file /etc/weewx/weewx.conf will be used.
Processing configuration file /etc/weewx/weewx.conf.
Traceback (most recent call last):
  File "/usr/share/weewx/", line 53, in <module>
  File "/usr/share/weewx/", line 45, in main
  File "/usr/share/weewx/weectllib/", line 233, in reconfigure_s                                 tation
  File "/usr/share/weewx/weecfg/", line 102, in station_reconfi                                 gure
    config_config(config_path, config_dict, dry_run=dry_run, *args, **kwargs)
  File "/usr/share/weewx/weecfg/", line 131, in config_config
    config_altitude(config_dict, altitude=altitude, no_prompt=no_prompt)
  File "/usr/share/weewx/weecfg/", line 181, in config_altitude
    raise ValueError(f"Unknown altitude unit {unit}")
ValueError: Unknown altitude unit feet
dpkg: error processing package python3-weewx (--configure):
 installed python3-weewx package post-installation script subprocess returned er                                 ror exit status 1
Processing triggers for man-db (2.9.4-2) ...
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

Peter Fletcher

Mar 27, 2023, 2:27:46 PM3/27/23
to weewx-development
Can I put in a vote for this, too, having been bitten by the same thing on a couple of occasions. I know we should all RTFM, and I usually do, but altitudes are generally in (plural) feet or meters, and it is a very easy slip to make!

Tom Keffer

Mar 27, 2023, 8:38:20 PM3/27/23
to weewx-development
Doing data validation with a Debian package is not something I have figured out. Maybe Matthew has. 

You can't simply flag an error and ask the user to try again because db_input, the mechanism for adding things to the debconf database, may not be in an interactive session.

If you do a pip install and use weectl station create, it will validate your input unless you specify --no-prompt. 

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
To view this discussion on the web visit

Vince Skahan

Mar 27, 2023, 9:36:22 PM3/27/23
to weewx-development
I read it a little differently.

I think they're asking that the underlying code use plural for altitude because it is unlike the altitude would ever be 1 foot/meter regardless of whether it's a pip/apt/yum installation.   (it's always 0 or 2 or 123 feet/meters etc.)

Alternately you could just fix just their garbage-in under the hood in configuring the station.   Looks like you could do so around line 167 in if you were so inclined with just a few lines for 'foot/feet' and 'meter/meters'.  Folks do seem to mess this one up a lot.

Maybe something like this (untested) ?

    if unit in ['feet']:
       unit = 'foot'
    elif unit in ['meters']:
       unit = 'meter'

Graham Eddy

Mar 27, 2023, 9:46:06 PM3/27/23
to weewx-development
i agree that this is what is being asked for, which is some kind of free-format description of altitude in local quirky dialect (i exaggerate for effect).
i think what is presently provided is the correct approach i.e. unequivocal in a supported weewx unit system

Peter Fletcher

Mar 27, 2023, 10:15:37 PM3/27/23
to weewx-development
I was certainly really thinking about the underlying code rather than the installation script. When specifying units of measurement, I think that using the singular form (foot or meter) is the quirky approach!

G Hammer

Apr 1, 2023, 7:51:04 AM4/1/23
to weewx-development
If I'm asking someone which system they use, I have never asked foot or meter. It's always do you prefer feet or meters.

Tom Keffer

Apr 1, 2023, 8:26:20 AM4/1/23
to weewx-development
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.


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

Peter Fletcher

Apr 1, 2023, 9:52:14 AM4/1/23
to Tom Keffer,

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.

You received this message because you are subscribed to a topic in the Google Groups "weewx-development" group.
To unsubscribe from this topic, visit
To unsubscribe from this group and all its topics, send an email to
To view this discussion on the web visit

Peter R. Fletcher <>
Home Page - 
Message has been deleted

matthew wall

Apr 1, 2023, 11:56:13 AM4/1/23

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/


Peter Fletcher

Apr 1, 2023, 5:41:13 PM4/1/23
to matthew wall,
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.
Reply all
Reply to author
0 new messages