It was "weectl station upgrade --what skins" as the offender.
The skins stuff that comes with core is Ftp, Mobile, Rsync, Seasons,
Smartphone, Standard - so my thought as a user is that I always am going to
want to upgrade the one(s) that I use along with the code stuff that pip
installs. In my case this means Rsync specifically, but I know others
might want the Ftp uploader. So for me, I would 'always' run that
optional --what command when updating weewx even though I don't use the
actual core skins at all.
Of course that begs the question of why the core Ftp and Rsync uploaders
are in skins to begin with. If they're core, shouldn't they just be in the
pip-installed tree and shouldn't their skin.conf content be in the core
weewx.conf always like other code ?
Anyway - timestamping the individual skins seems like the quickest way to
get back to 'nothing breaks a pre-existing installation' although I did
want to bring up that weewx-data/user/{bin,skins} option just in case you
wanted to get a more complete architectural split of core-vs-user stuff.
I'm appreciative of any solution that does not break a pre-existing
anything.
On Wednesday, May 3, 2023 at 2:52:28 PM UTC-7 Tom Keffer wrote:
> Wait. Are you saying a pip upgrade broke the skins? It's not supposed to
> touch anything in the user data area.
>
> Or, do you mean
>
> *weectl station upgrade --what skins *
>
> broke it? If so, this is the reason why we make a user explicitly call out
> a skins upgrade. Skin upgrades were impossible with setup.py installs. Now
> they're possible, but you have to ask for it explicitly.
>
> We could timestamp the individual skins. I'm liking that idea. I get the
> advantage if a user has installed some other skin.
>
> On Wed, May 3, 2023 at 2:36 PM Vince Skahan <[email protected]> wrote:
>
>> Bottom line is an upgrade should never break anything there previously.
>>
>> Historically a weewx setup.py upgrade left any user additions under skins
>> as-is and still present and working. The core was simply updated and no
>> further user action was required.
>>
>> But now a v5a29 pip upgrade breaks any skin previously added to the skins
>> directory.
>>
>> - Those previously installed skins are still mentioned in weewx.conf
>> but their corresponding skins/whatever subdirectory isn't there anymore
>> since it's been moved to skins.<timestamp>/whatever. So the user
>> additions
>> are broken as a result.
>>
>> To me this is the core vs. user directories separation thing again.
>> Upgrades don't break things in bin because bin/user is never touched....but
>> there is a flat skins directory that both core and users can add to.
>> Neither side should ever simply move the whole skins tree aside because it
>> breaks the other guys.
>>
>> Some possibilities:
>>
>> - Do the skins/Seasons.<timestamp> option you suggested for core
>> skins/whatever subdirectories. There's just a half-dozen of those. Loop
>> through them, do a mv before putting the new subdirectory into place.
>>
>>
>> - I wouldn't do the skins/Seasons.<version> option probably
>>
>>
>> - But if you really want to cut the cord and split out core vs. user
>> content explicitly, I wonder if something more like the following might
>> be
>> worth thinking about long-term as this is a major version update to weewx
>> so perhaps there's an opportunity:
>> - add a weewx-data/user tree for all user additions
>> - add a weewx-data/user/bin subdirectory for their code rather
>> than the existing bin/user tree
>> - add a weewx-data/user/skins for their skins rather than being
>> alongside core skins in the existing skins tree
>> - and make weewx-data/user as a whole something nothing other than
>> the extension installer ever alters
>> - (admittedly I'm ignoring v4=>v5 transition risk and coding cost,
>> but I thought I'd suggest it just in case)
>>
>>
>> On Wednesday, May 3, 2023 at 1:27:33 PM UTC-7 Tom Keffer wrote:
>>
>>> Not following. What should the expected behavior be? I suppose we could
>>> move a timestamped version of the old core skin aside, and install the new
>>> version. Is that what you're thinking? You'd end up with something like
>>>
>>> skins
>>> Seasons
>>> Seasons.20230422
>>> Standard
>>> Standard.20230422
>>> etc.
>>>
>>> But, it's not clear to me why that's any better than what we're doing.
>>>
>>> Or, we could do
>>>
>>> skins
>>> Seasons
>>> Seasons-v5.0.0a29
>>> Standard
>>> Standard-v5.0.0a29
>>>
>>> That's not really an "upgrade", and it's a new pattern for WeeWX, but
>>> it's certainly possible.
>>>
>>> Let me know what you're thinking.
>>>
>>> -tk
>>>
>>> On Wed, May 3, 2023 at 9:20 AM Vince Skahan <[email protected]> wrote:
>>>
>>>> I upgraded a28 to a29 and followed the upgrade guide and ran "weectl
>>>> station upgrade --what skins" and got some very unexpected behavior.
>>>>
>>>> From the docs I 'thought' that it would upgrade only the content of the
>>>> various core skins.
>>>>
>>>> What happened is the entire skins dir was moved aside into the
>>>> timestamped directory and pip installed 'only' the core skins into a new
>>>> clean weewx-data/skins directory. Very unexpected behavior.
>>>>
>>>> Is it possible to not move any third-party skins that aren't core aside
>>>> and 'only' update the core skins via weectl ?
>>>>
>>>> I guess I'm looking for something similar to how bin/user is never
>>>> altered. It might be too much of a stretch to do weewx-data/skins/user to
>>>> get there that way, but moving the whole skins tree aside including user
>>>> additions probably needs rethinking a bit...
>>>>
>>>>
>>>> --
>>>> 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/4dd28156-68ae-45ff-bd47-60dcdbd634c1n%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/weewx-development/4dd28156-68ae-45ff-bd47-60dcdbd634c1n%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/71bd57a1-e675-4fb7-b450-1a8053d3992fn%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/weewx-development/71bd57a1-e675-4fb7-b450-1a8053d3992fn%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/30b5f63f-3aad-4ccf-825d-1758e518fb07n%40googlegroups.com.
