search

conda-forge / jplephem-feedstock

A conda-smithy repository for jplephem.
BSD 3-Clause "New" or "Revised" License
0 stars 9 forks source link

from jplephem.pck import DAF, PCK gives a traceback #17

Closed ReimarBauer closed 4 years ago

ReimarBauer commented 4 years ago

Issue: In a complete new env we can't import needed modules
Environment (conda create -n pbenv jplephem):

from jplephem.pck import DAF, PCK Traceback (most recent call last):File "", line 1, in ModuleNotFoundError: No module named 'jplephem.pck


Likly after the missing merges are fixed this will be solved. We found that pip install jplephem --upgrade works

see also: https://bitbucket.org/wxmetvis/mss/issues/515/modulenotfounderror-no-module-named

brandon-rhodes commented 4 years ago

Thanks for the report! Several users banded together and figured out how to get the conda-distributed version of jplephem upgraded; it was stuck on an old version.

Conda now looks to be up to 1.12: https://anaconda.org/conda-forge/jplephem

Could you try again and see if the conda-supplied version now fixes this error? Thanks!

ReimarBauer commented 4 years ago

Verified fixed. Thx :)

May be we could just add a new build number to this skyfield feedstock and add the dependency >=2.12, see https://github.com/conda-forge/skyfield-feedstock/issues/32

This would help a lot other projects.

ReimarBauer commented 4 years ago

2.12 (repeated the typo) ;)

brandon-rhodes commented 4 years ago

Oh, now that I read this, your no-op update to the other feedstock makes more sense (except, I guess, that I didn't see it increment any build numbers?).

At this point, are things fixed for new installs — does installing Skyfield auto-install the new version of jplephem? In which case, a bump of the Skyfield package would help folks who had (a) installed Skyfield and gotten the old jplephem, (b) hadn't fixed it themselves, (c) hadn't uninstalled Skyfield, and (d) then run a conda-upgrade-all step after the bumped version comes out?

ReimarBauer commented 4 years ago

Did a missing save, I guess, sorry.

A new install of skyfield will use the newest build of jplephem. This is the simplest solution for our project where we only get jplephem with skyfield. Otherwise I have to add there the package with the fixation and to create a new build of our software. Later after a new release of skyfield I would have to undo this.

All having skyfield installed had in their dependency until the upgrade is triggered the old build.
But once they had an issue and try upgrade they get the newest version and not any other of jplephem.

From https://conda-forge.org/docs/maintainer/updating_pkgs.html

Bumping the build number

The build number is increased when the source code for the package has not changed but you need to make a new build. As a rule of thumb, the build number is increased whenever a new package with the same version needs to be uploaded to the conda-forge channel.

Examples for needing to increase the build number are

updating the pinned dependencies after a rerendering

Fixing wrong dependencies

When the package version changes you should reset the build number back to

brandon-rhodes commented 4 years ago

Now that I see the dependency version number indeed changes in your diff, it makes perfect sense to me why a new release is needed. Thanks!