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/CAPq0zEAS2HjMONgPunE26XCB9Q-y7XRoQDEkRw%2B3Z0eXFEG_RQ%40mail.gmail.com.
