a29 pip upgrade unexpected behavior

[Vince Skahan]

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...

[Tom Keffer]

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

--
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/4dd28156-68ae-45ff-bd47-60dcdbd634c1n%40googlegroups.com.

[Vince Skahan]

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)

[Tom Keffer]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/71bd57a1-e675-4fb7-b450-1a8053d3992fn%40googlegroups.com.

[Vince Skahan]

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.

[Tom Keffer]

Give it a try now. It backs up the skins individually.

v5.0.0a30

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/30b5f63f-3aad-4ccf-825d-1758e518fb07n%40googlegroups.com.

[Vince Skahan]

Perfect.  Thanks !