On Tuesday, November 8, 2022 at 12:10:22 AM UTC-5 [email protected] wrote:
> I'll attach an obfuscated weewx.conf from my system. Any new solution
> would have to be able to generate something that is functionally the same
> as this, at a very minimum.
>
on a first install, the install mechanism (either pip, venv, apt-pre,
yum-pre, etc) would install the python code in the correct place. part of
that 'code' is the reference weewx.conf and reference skins - those would
live with the python code and would be read-only.
then you would be prompted (as you are now) for the minimal set of
information required to create a station instance. this would probably be
done by wee_ctl, for example as part of 'wee_ctl create-station'. it would
use the reference weewx.conf then modify with whatever you prompted it with.
might have to add an option to the driver prompt so you could download a
driver during the initial install.
> A couple toplevel questions I guess:
>
> - would we need to run wee_ctl potentially dozens and dozens of times
> to build up an aggregate .conf file (or equivalent) like my big one that
> I've attached ?
>
> the intent is not to create a config file editor. you just edit your
config file manually as you do now.
the wee_config tool would provide config-specific options, such as validate
("is there anything wrong with my config?") and update ("modify my config
to match whatever weewx version is installed"). weewx will be backward
compatible (as much as possible), but if there are breaking changes along
the way, keeping that check/update function in wee_config will prevent
unexpected behaviour. installation/updating would not modify any configs -
weewxd would just die after an upgrade, with messages about "this feature
is no longer compatible", leaving you to modify the config file (directly
and/or with wee_config to help).
> - 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
>
> - could a wee_ctl command be made idempotent so that a one-liner
> change to the (theoretical) data file would only do one thing differently
>
> i think that idempotence is desirable for every utility. in the case of
conf modifications, any tool that modifies a config must leave the previous
state next to the current state, using a naming convention that makes the
process infinitely repeatable without losing initial state.
> And lastly:
>
> - 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.
>
> one config file for each station instance. for most weewx installations,
that means a single config file.
if you want to maintain multiple weewx versions concurrently (e.g., for
regression testing), or if you have multiple station instances (e.g., the
weewx-multi use case), then managing the multiple conf files is up to you.
it must be possible (and i would argue easy, at least if we do this right),
but it is not the primary use case.
where the conf lives is not yet clear. for apt/yum it is clear - they live
in /etc/weewx. for a python install, we are considering ~/weewx of the
user who created the station instance (not necessarily the same as the user
who installed weewx). from a support point of view, it would be nice if
the conf file (and skins and database) were always in the same place. i'm
not sure if that is possible, since the developer use case wants these in a
single directory in the user's home directory space, whereas that is
non-standard for an apt/yum install.
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.
not sure if wee_ctl is going to help much for the salt/ansible/docker use
case - so far it has been (1) to make weewx more pythonic, and (2) make it
easier for users to do non-python things (e.g., install the appropriate
init file(s)), and (3) move the post install stuff into a unified code for
deb/rpm (which has added benefit of making bsd installs use the same
pattern and code).
m
--
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/7556b2ed-9f3e-4b4c-b37a-bf11adcb8c0fn%40googlegroups.com.
