Huh ? Packages have been available for debian(ish) and redhat(ish) operating systems for a number of years. Those packages install the prerequisite/corequisite packages that are needed to make weewx work and install things where those operating systems install things. What exactly is missing there currently ?
I'd suggest almost all of the (newbie) pi users are using the packaged version these days, based on the questions we see. Upgrades have always just plain worked in my experience, for both debian(ish) and redhat/fedora systems, regardless of whether you were packaged or setup.py for your installation method.....as long as you stick with the method of installing weewx you picked. The structure of weewx.conf is a bit difficult to script around due to its configobj origins, but lots of work has been done to make the items therein unique enough to let you run sed inline (or use ansible, etc.) against that file to salt to taste. Most people shouldn't have to do anything for a vanilla weewx system other than install the package interactively and answer the prompts it provides. The extension installer also helps a lot, permitting you to add/delete skins+extensions with one command. So if you have well-formed skins and extensions you might never need to even edit weewx.conf - but of course some require a 'lot' of touch labor to tweak to your liking. That's the skins/extensions bug/feature, not the core weewx product's limitations. FWIW, I can build my whole system totally scripted using either setup.py 'or' a packaged weewx by installing weewx and running sed inline on the weewx.conf file, then resetting the daemon. That's not bad. (ok - I don't do it 100% scripted actually, I would have a few blocks of configs to add to some extensions needing a lot of hand-tweaking to look+act the way I want them to do, but again that's an issue with those extensions. I can certainly go from nothing-to-done totally scripted for 98% of my setup) While I'd also like to see a more modular weewx.conf structure, that's come up a lot in the past and the decision was made to stay the course as-is there. But sure I'd agree that moving to a less python configobj kind of structure to something more mainstream even if it's a ini file would be cool to see, but there are a zillion plus/minus things there as well. It was an interesting conversation way back when.... -- 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/f8013f7d-76ba-4aba-a210-0960d8313526%40googlegroups.com.
