Discussion (and answer) moved to issue #552 <https://github.com/weewx/weewx/issues/552>.
On Fri, May 22, 2020 at 9:53 AM Till Maas <opensou...@till.name> wrote: > On Sun, May 10, 2020 at 10:19:41AM -0700, mwall wrote: > > > > > > On Sunday, May 10, 2020 at 11:37:17 AM UTC-4, Till Maas wrote: > > > > > > > > > > 4. weewx.conf gets automatically patched by an upgrade. This is a > big > > > > feature of weewx over the standard package upgrades, which merely > ask > > > a > > > > user if they want to "merge" their old config file with an > incoming, > > > new > > > > config file. > > > > > > What exactly is happening here? > > > > > > > the weewx configuration file (nominally weewx.conf) is modified during > the > > upgrade. if you use setup.py and install a new release of weewx on top > of > > an existing one, it will modify the existing weewx.conf so it will work > > with the latest release. it saves the old file, of course. this works > on > > weewx config files all the way back to 1.0 > > Did you consider upgrading the config when running weewx the first time > after upgrade instead of during the upgrade process? Could this be an > alternative? This could still be enabled/disabled in the config file. > > Another possibility to simplify things might be to have a defaults, > read-only config file and have the user provide a config file that > contains only the changes. This does not solve renaming config options, > though. > > > a long long time ago, the configuration modification code was embedded > in > > setup.py. it has since been moved to a module, and it can be called > > independently of setup.py using wee_config. > > Awesome, this simplifies this already. :-) > > > this is tricky. six and daemon are just one file each, and they > basically > > never change. imho, it does not make sense to create a dependency for > each > > of them - just distribute them as part of weewx, and do updates as > > necessary. > > If they are going to be bundled, they still need to be moved in a custom > weewx namespace to ensure that they do not collide with the system > package. Therefore bundling seems to add more costs than adding a > dependency. At least six is a very common package, not sure about > daemon. > > > > The user directory is the directory where wee_extension adds new > > > extensions, isn't it? > > > > > > On first thought, the best approach for me would be that the > recommended > > > way to install extensions would be that they use pip as well for > > > installation. Everything that wee_extensions installs, would be best > > > moved to /var/lib/weewx/user or similar to ensure that it does not > > > conflict with the packaged files from weewx. Seems like it would be > > > $HOME/.local/share or $XDG_DATA_HOME if installing per-user. There > does > > > not seem to be a better counter part for /var/lib. > > > > > > > agree that /var/lib is the appropriate place for this kind of thing. > right > > now /var/lib/weewx is where the sqlite databases reside. adding a > > /var/lib/weewx/user directory would not be unreasonable, but it would > > require more python path munging. > > The user directory would need to be in $HOME, otherwise there would be > permission challenges. > > Thanks > Till > > -- > 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/20200522165330.GG25070%40genius.invalid > . > -- 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/CAPq0zEDLWKEG228y1T548UR7htTs1dz6ZvmUd%2BNo3s1CxYNqJg%40mail.gmail.com.
