Questions on the new skyfield info just posted a few days ago on the Github

[DR]

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.

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.


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.

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.


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?


thx.  Dale

[John Kline]

On Jul 25, 2026, at 12:46 PM, DR <wxe...@gmail.com> 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 weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/cee66acf-04c9-4669-b6d4-835b0725c157%40gmail.com.

[DR]

Very very helpful for me to begin to understand how these things work.


I appreciate you taking the time to clarify.  I'll look again to see
where I read about the install again after modifying a skin, I may not
got the gist of it right.

Lots of good info in your summary!  Dale

[John Kline]

Hi Dale,

A follow-up on your “which engine is doing the calculations” question, since it has a simpler answer now…

As of 1.16 (released yesterday), everything astronomical the built-in almanac ever answered is computed natively in Skyfield — including the moon.subsolar_lat example I gave you.

The only attributes that still fall through to PyEphem are a_epoch (an epoch stamp, not astronomy) and PyEphem's own deprecated rise_time/set_time/transit_time family, and that's deliberate — rise/set/transit are the supported native vocabulary.

Of course, it is still the case that, if you disable stars in weewx-skyfield, it will fall through to PyEphem; and, if you pick dates earlier then July 29, 1899 or later than October 9, 2053, it will fall through to PyEphem.

Cheers,

John

On Jul 25, 2026, at 1:34 PM, John Kline <jo...@johnkline.com> wrote:



[DR]

Thanks for the update.

I cannot fathom the amount of work you've put into bringing this to the
group.  Thank  you.