> On Jul 25, 2026, at 12:46 PM, DR <[email protected]> wrote: > > There was a github info on the skyfield replacement for pyephem. > > I can't find the answers to a few questions: > > a) when skyfield is added, does it sniff through all the *.conf files in the > root of the weewx-data and insert the line that enables it to be run ahead of > pyephem, or only the weewx.conf file in the weewx-data directory; of concern > if there are several weewx configs for those of us running a couple of types > of stations. There is no “sniffing” involved. WeeWX added a feature that allows an extension to insert itself ahead of pyephem (if pyephem is installed) and ahead of the built-in almanac. As such, at report time, the extension’s almanac is queried first to resolve the almanac tag. If it doesn’t, the pyephem/built-in almanac(s) will be queried. > > b) If those config files are modified, there is the implication at least in > the FAQ that the whole installation of Skyfield needs to be run again, which > seems a bit odd but lends credence to the idea that the installation of it > does look through and modify the files. I’m not sure if you are referring to my almanac extension (https://github.com/chaunceygardiner/weewx-skyfield) or https://github.com/roe-dl/weewx-skyfield-almanac; but, whichever one makes you think you have to continuously reinstall, you should let us know so we can clarify the documentation. If new versions of the extensions are released, you do need to reinstall to use that new version; but changing other skins, adding almanac tags, etc. do not require you to reinstall the skyfield almanac. > > > c) Is there any way of seeing if skyfield is doing the calculations, or if > pyephem is? The notes indicate that if installed, skyfield will be tried > first, then fall back to pyephem. I can answer this for my extension:
Yes, there's a test for the no-PyEphem case. The test suite has a fixture that simulates a machine without PyEphem installed (it removes the ephem module and leaves only the Skyfield almanac registered), and an audit test (TestSkyfieldOnlyAudit) that requires every supported tag to evaluate correctly in that configuration. So the Skyfield engine is proven to answer everything it claims to on its own, not silently via PyEphem. On which engine is doing the calculations — it's actually a bit stronger than "try Skyfield first, then fall back." Once the extension is registered, Skyfield computes everything it knows how to compute. PyEphem is consulted only in three narrow, by-design cases: 1. Attributes Skyfield doesn't compute at all (direct PyEphem extras like moon.subsolar_lat). 2. Named-star tags when the star catalog is disabled (but you would have to go out of your way to disable it). 3. Dates far enough outside the bundled DE421 ephemeris span (1899–2053) that a search window can't complete. Ways to see it for yourself: - Check the startup log. If the extension registered, syslog shows: Skyfield almanac registered; reports will use Skyfield for almanac computations. If that line is present, your report tags are coming from Skyfield except for the three cases above. - The definitive experiment — the same thing the test suite does: pip uninstall ephem in your WeeWX virtual environment and restart. Anything that still evaluates is pure Skyfield. (The handful of PyEphem-only attributes become per-tag errors, not aborted reports, so it's safe to try.) - Look at the values. The README's "Differences from PyEphem" section lists tags where the two engines measurably disagree (e.g., Jupiter's central meridian longitude differs by ~0.8°, and twilight with a custom horizon is geometric per USNO rather than refracted). If your output matches the documented Skyfield/USNO value, Skyfield computed it. > > d) If at this point skyfield is the preferred option going forward and will > have not only more accuracy (I really don't need it but seems like a good > thing) along with an ephemeris which will be updated, maybe it is a > worthwhile thing to get a new install of my whole RaspPi system and try to > remove pyephem? Maybe this isn't even possible, and my RaspOS skills are > rudimentary for knowing if this is a worthwhile thing. I’m not sure who would bestow the “preferred” label. Probably Tom could make that pronouncement; but I *think* he is in the camp that PyEphem is good enough. I think it is a reasonable position to regard PyEphem as good enough. As fore starting over, you don’t need to start over to remove PyEphem (depending on how you installed WeeWX, that might be a pipe uninstall or an apt remove). > > > e) while I'm asking, there were implications that Trixie broke a few things > by imposing a higher level of security, so I was happy to have my install > just working and never upgraded to that version. Is there still some parts > of the whole WeeWx ensemble which isn't happy with Trixie, or have those > problems (if they existed for ordinary users) been taken care of in WeeWx 5.4? I’ll pass on answering this question as there are others more familiar with the issues. > > > thx. Dale > > > > > -- > You received this message because you are subscribed to the Google Groups > "weewx-user" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/weewx-user/cee66acf-04c9-4669-b6d4-835b0725c157%40gmail.com. -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/weewx-user/96D799C8-7754-4C70-BF1F-9BC930E581C9%40johnkline.com.
