Maybe I've missed the whole point of these proposed changes, but I'll offer 
my experience on the offhand it might help.
For a *very* long time, when I was working, we had two very large sets of 
tools, the first in Perl, then a complete re-write
in Python.  In both cases, all the configs (a LOT of them) were coded in 
the native language and imported (use/require or include).
In both cases, it allowed simple syntax error checking (perl -wc, and the 
equivalent for python). The other advantage was zero
code for accessing the config data; you just used it.  Those configs were 
native data structures, so any variety of data types
the languages supported could be used.  The python versions even used 
lamda's (which I hated), because the idea was that the
configs were just data, no code.  Not necessarily relevant here. One other 
piece; the consumed configs could be written out using
DataDumper (more or less).  For another code set, I also used pickle files 
to store/retrieve state data.

As for weewx, I like having the code locally in a user's directory 
(setup.py type install).  Avoiding sudo isn't so hard; if I remember right
it's just a matter of pointing the PID file somewhere you have write 
permissions and getting added to the groups necessary to get at
the weather station data (dialout in my case).  I have a start-up script in 
perl that runs from crontab (as weewx, not root).  As for the
weewx.conf; it's usable, but seems awkward having to keep track of 
brackets, and does require a library to consume (as does all the
other mentioned formats), whereas native code is just included.

Is there a concise problem statement related to all this?  It's funny that 
over the years (decades) I think much better working from
a problem statement.

Chris

On Sunday, November 6, 2022 at 6:45:17 PM UTC-7 [email protected] wrote:

> Everything I’ve wanted to do in weeex.conf and skin.conf could only be 
> done via a text editor. The current ini format (or toml format) is much 
> easier to edit than json or yaml.
>
> For example: I’ve been writing an Alexa skill to use data that Weewx 
> writes out - among other things - to announce weather related data and 
> forecasts. Alexa uses JSON for many things. It’s not a more difficult a way 
> to present the data but it’s full of little gotchas that are annoying. 
>
> Sent from my iPhone
>
> On Nov 6, 2022, at 5:15 PM, Vince Skahan <[email protected]> wrote:
>
> On Sunday, November 6, 2022 at 3:39:54 PM UTC-8 Tom Keffer wrote:
>
>> One of the things I disliked about wview was its many configuration files 
>> and then, later, its database-oriented configuration. I wanted everything 
>> in one, easily readable, place.
>>
>> To do edits of the config file it's best to read it in using configobj, 
>> do the edits in Python, then write it back out. Unless I'm missing 
>> something, I don't see why JSON would be any different.
>>
>
> Yes, I remember that.  I didn't mind the db, but I sure didn't want to 
> need to use the gui to tweak the defaults.
>
> What I'm looking for is a way to 100% totally script a very customized 
> installation.  That is not possible using configobj as far as I've been 
> able to tell in several years of trying to get ansible to do so, although I 
> suspect some crazy complicated python might get me there.  
>
> I *think* it's possible in ansible if it was in JSON if that matters any. 
>  Really comes down to how abstract and flexible the scripting language 
> tools are. Nobody writes tools around configobj is the basic problem.
>
> I would like to be able to:
>
>    - add lines
>    - remove lines
>    - edit lines
>    - comment/uncomment lines
>    - add/remove/edit comments at the end of lines as documentation for 
>    myself
>    - 'hopefully' without writing complicated python code
>
> The whole purpose of DevOps tools is to not need to write complicated 
> python/perl/whatever code.
>
> My weewx.conf is over 400 lines if I remove all commented and 
> whitespace-only lines.  I'd be happy to pass an obfuscated one along if 
> it'll help show what I'd love to be able to fully script.
>
> But yes, ultimately it's a hierarchy of stuff there.  I would certainly 
> agree that once you reach the point of writing a lot of custom code to 
> parse/manipulate the file, it doesn't matter if it's configobj or JSON or 
> whatever because you're writing a lot of custom complicated code no matter 
> what...
>
> -- 
> 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/b3ed6e89-cfd5-4c4d-9338-c8e42f16a697n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-development/b3ed6e89-cfd5-4c4d-9338-c8e42f16a697n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>

-- 
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/3fca0dff-f34a-4520-ad57-e219d0a159dbn%40googlegroups.com.

Reply via email to