Yes, this would be for V5. Most likely Python 2.7 would be dropped.

The problem is not the configobj format, it's the future readonly nature of
Python installs. The config file (and skins) are considered "data", and the
only way to include "data'' is within a Python package. That package might
be in a zipfile or Python egg, hence its readonly nature.

Furthermore, installs can only be done within "sys.prefix
<https://docs.python.org/3/library/sys.html#sys.prefix>". You can't just
roam around the file system and install things wherever you like. Hence,
a more unixy setup could not be done with pip, even if we wanted to.

While I was at first put off by this decision, I can see their point. For
one thing, it means sudo is no longer necessary. You can also install into
a virtual environment as easily as into the system's python.

Regarding the format, I suppose we could move to a different format besides
configobj, but it has served us well --- I don't see a compelling reason to
change. For one thing, changing would break a *lot* of things.

See this thread <https://github.com/pypa/setuptools/discussions/2648>. It's
hard to follow without spending some time in Python packaging land, but it
discusses these issues.

-tk

On Sun, Nov 6, 2022 at 11:03 AM Vince Skahan <vinceska...@gmail.com> wrote:

> This one scares me, as previous versions have definitely tweaked the
> contents along the way of the upgrade path from version to version.   Is
> this something for a future 5.x major version that might have breaking
> changes like dropping python2 support or the like ?
>
> Has there been any thought to dumping configobj format completely and
> going to a more modern mainstream format (JSON, YAML, etc.) or alternately
> more of a unixy setup ala something like /etc/weewx/config.d/<whatever>
> type files that can be simply included much like webserver configs do it ?
>
> On Sunday, November 6, 2022 at 6:46:03 AM UTC-8 Tom Keffer wrote:
>
>> Yes, all the time.
>>
>> Semantically, 'configobj' does a round trip, but textually, it leaves
>> much to desire.
>>
>> Going forward, the intention is to start treating weewx.conf as
>> "readonly". The installer will not try to "update" it, not even to change
>> the version number. Any changes would be up to you, perhaps with the aid of
>> a tool (although, if you do use a tool, you can expect the same textual
>> changes).
>>
>> The setup.py method of install is being deprecated, especially the
>> imperative approach that WeeWX takes where many install methods are
>> overwritten. Instead, the configuration will be specified declaratively
>> using a pyproject.toml file. That necessarily requires that weewx.conf be
>> treated as readonly. The actual install would be done by using pip.
>>
>> -tk
>>
>> On Sun, Nov 6, 2022 at 4:55 AM Greg Troxel <g...@lexort.com> wrote:
>>
>>>
>>> (I have been running WeeWX since the very end of 2017, and updated a few
>>> times.  I'm building with setup.py on NetBSD, but I'm quite used to
>>> python.)
>>>
>>> There is some config file auto update/merge stuff.   My usual practice
>>> is to keep my config file matching the default example in the source
>>> code, except for things that I intend to change, and after an update (of
>>> almost anything, not just WeeWX) I try to diff and reduce unintended
>>> diffs.  And yes, I think this is normal :-)
>>>
>>> I have noticed that after doing a WeeWX upgrade, which tries to do
>>> something that feels like a 3-way merge from old to new configs with
>>> mine, and almost entirely gets it right, that the config file differs
>>> from the example in two ways:
>>>
>>>   - a bunch of whitespace changes, not important but annoying
>>>   - quoted strings are no longer quoted
>>>
>>> Because of this I have tended to update less often than I might.
>>>
>>> A few minutes ago I glanced at configobj and saw the magic words "round
>>> tripper" at https://pypi.org/project/configobj/
>>>
>>>   ConfigObj is a simple but powerful config file reader and writer: an
>>>   ini file round tripper.
>>>
>>>
>>> So I wonder if the changes are something configobj views as
>>> normalization, and if instead
>>>
>>>   - It should be configured with WeeWX'S whitespace and qouting rules.
>>>   - WeeWX should round-trip the default files
>>>
>>> or if
>>>
>>>   - I'm confused.
>>>   - It's an artifact of my system (but I have configobj 5.0.6 which is
>>> current).
>>>
>>> Do other people see this?
>>>
>>> --
>>> 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 weewx-developm...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-development/rmitu3cw8fm.fsf%40s1.lexort.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 weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/7e89e9d5-81c2-47d0-b251-03a1a0e176cfn%40googlegroups.com
> <https://groups.google.com/d/msgid/weewx-development/7e89e9d5-81c2-47d0-b251-03a1a0e176cfn%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 weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEC_YK3Ugk%2B%3DgZQSMfukTvH7Nx6AOFFekA7cA58LtLOo1Q%40mail.gmail.com.

Reply via email to