Give it a try now. It backs up the skins individually. v5.0.0a30
On Wed, May 3, 2023 at 3:06 PM Vince Skahan <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/weewx-development/30b5f63f-3aad-4ccf-825d-1758e518fb07n%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/CAPq0zECJUBf7--wF-NkRKJ74VLZ_xBo6ue95FAGnbNzwhG_dxw%40mail.gmail.com.
