ephem version 4.1.2 `AttributeError: 'Sun' object has no attribute 'ha'`

[kovar-ursa]

import ephem
ephem.__version__
foo = geospatial.df_row_to_timeofday(glitch.iloc[0], glitch.iloc[-1])

ephem is version 4.1.2 now

That code used to work (absent the previously reported bug.) It now produces the following for all cases, not just the edge case:

~/work/a50/tracklib/geospatial.py in df_row_to_timeofday(start, end)
    400     # There is a bug in ephem for very specific locations, thus the try/except
    401     try:
--> 402         next_sunrise = utc.localize(observer.next_rising(ephem.Sun()).datetime())
    403         next_sunset = utc.localize(observer.next_setting(ephem.Sun()).datetime())
    404     except ValueError:

~/miniforge3/envs/a50-dev/lib/python3.9/site-packages/ephem/__init__.py in next_rising(self, body, start, use_center)
    437     def next_rising(self, body, start=None, use_center=False):
    438         """Search for the given body's next rising"""
--> 439         return self._find_rise_or_set(body, start, use_center, +1, True)
    440 
    441     @describe_riset_search

~/miniforge3/envs/a50-dev/lib/python3.9/site-packages/ephem/__init__.py in _find_rise_or_set(self, body, start, use_center, direction, do_rising)
    471                 else:
    472                     target_ha = abs_target_ha    # sets in west (az 180-360)
--> 473                 ha = body.ha
    474                 difference = target_ha - ha
    475                 if prev_ha is None:

AttributeError: 'Sun' object has no attribute 'ha'

[brandon-rhodes]

@kovar-ursa — Well, drat. When I run from source, everything works, and I've seen no errors like this in CI; but when I install the package with pip, I get the same error you do! Let me dig in and try to find a difference.

[brandon-rhodes]

I am mystified about how the 4.1.2 build produced compiled packages that are missing code present in the 4.1.2 version in the repository. Before investigating further, I'm attempting a new release, since a bugfix release is due anyway and might fix this "ha" problem at the same time. It's now building on GitHub and should self-publish to PyPI within about an hour. Once 4.1.3 is available, we can see if it's still missing the new "ha" attribute.

Thanks for letting me know!

[kovar-ursa]

Greetings, Happy to help. 'tis a most helpful package. I'm only using a very small piece of it, but it solves that piece perfectly.

[brandon-rhodes]

Well, it didn't work. Version 4.1.3 also built successfully and passed all its tests, but when pip installed doesn't have the "ha" attribute on the Sun. Time for me to stare really hard at this problem and see if I can think of something.

[kovar-ursa]

I've lost hours, and even days, to this sort of thing. I'm with you in spirit!

[brandon-rhodes]

It turns out my local test was a false positive! The test file was in a directory that contained an ephem/ directory inside of which was an older version of the library, that of course was throwing the error.

Once I moved into a fresh directory and did a fresh install, the new version worked fine.

Somehow, in a way I don't quite understand, an old binary for libastro was somehow getting imported at the same time as a Python __init__.py that was clearly modern and wanted to use the new .ha attribute.

So on my system, at least, the new 4.1.3 runs the test file above just fine. Could you double-check on your end? Thanks!

[kovar-ursa]

Greetings,

It works on the known use case!

I've several hundred thousand points so it may hiccup on something else. Will let you know if so.

Thanks very much!

-David