Split out IERS Earth Rotation and Leap Second files into separate package - #14819
Conversation
|
Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.
|
|
👋 Thank you for your draft pull request! Do you know that you can use |
|
@astrofrog - excellent, thanks for diving in to this! I am a totally swamped this week but look forward to checking this out next week. |
mhvk
left a comment
There was a problem hiding this comment.
It is nice that this looks easy! The one overall question I have is to what extent we use astropy_iers_data in examples; my sense would be to keep it as an implementation detail, i.e., ensure that everything that is needed can be done via astropy.utils.iers. (Right now, this only affects the old-style IERS B readme, which was not really exposed; see in-line comment.)
| ``eopc04_IAU2000.62-now``), do something like this example with an | ||
| excerpt that is used for testing:: | ||
|
|
||
| >>> from astropy_iers_data import IERS_B_IAU2000_README |
There was a problem hiding this comment.
Seeing this example, I think we should indeed add the readme to astropy_iers_data (it is a TODO right now), but it might also make sense to hide the package from the user here, i.e., do from astropy.utils.iers import IERS_B, IERS_B_IAU2000_README
There was a problem hiding this comment.
On second thoughts, I wonder whether, as it is mainly a backward-compatibility thing, whether the IAU2000 file should actually just remain in astropy core, since we don't have to move it and it should never need to be updated?
taldcroft
left a comment
There was a problem hiding this comment.
This looks pretty uncontroversial!
Auto-updating astropy-iers-data at a reasonable cadence with date-based versions seems good. Likewise keeping the astropy requirement synced up also would be a good thing.
| ``eopc04_IAU2000.62-now``), do something like this example with an | ||
| excerpt that is used for testing:: | ||
|
|
||
| >>> from astropy_iers_data import IERS_B_IAU2000_README |
|
This also needs a doc update: |
|
Before this is merged, we need to do org-level stuff:
|
|
@pllim - the repo now exists: https://github.com/astropy/astropy-iers-data and I have only pushed basic infrastructure to @taldcroft @mhvk @pllim - please take a look at astropy/astropy-iers-data#1 which is a PR adding the main content to the astropy-iers-data package. It would be good to have this reviewed properly before pushing to main, and there are a few open questions. |
|
So who are the official maintainers for this new package? I need to know who to bug when things break there. 😉 Preferably at least 2 people who are responsive. |
|
@pllim - I'm happy to be one of the maintainers |
…nt working directory when using IERS_A.open/read
Co-authored-by: P. L. Lim <[email protected]>
|
Still waiting on conda-forge/staged-recipes#23209 at this point, it could be a little while as some other Python packages were ready for review a few weeks ago but are still waiting |
|
See #15013 for a companion PR to adjust the auto-update workflow (should be merged after this one) |
|
Why is conda-forge so slow? Do they have to do security audit or something? How long you think we have to wait? |
|
@mhvk that is fine for me. It would also allow a simple backport of the data package. |
|
@pllim - the conda-forge package is now available: https://anaconda.org/conda-forge/astropy-iers-data so I think we can proceed with this? |
|
|
|
Huh weird it is there on the conda forge channel - does conda complain about not finding the package? |
|
See https://anaconda.org/conda-forge/astropy-iers-data/files for the files |
|
Let me see... I was letting it run in the background. Took a very long time and now it wants to update a lot of packages. Is this normal? Why is a simple data package so demanding? |
|
On a clean conda env with Python 3.11, it still pulls in other stuff but does not take as long or as many: I see nothing amiss in https://github.com/conda-forge/astropy-iers-data-feedstock/blob/main/recipe/meta.yaml so maybe this is just conda black magic I should walk away from. I don't think this behavior blocks the PR. |
pllim
left a comment
There was a problem hiding this comment.
Let's do a Friday evening merge on breaking changes! 😉
Thanks, all!
As discussed in #14756 (comment), it might be worth splitting the IERS Earth Rotation and Leap Second files (along with the URLs and ReadMe files) out into a dedicated package, so this is an experimental PR doing this. The experimental astropy-iers-data package can be found here:
https://github.com/astrofrog/astropy-iers-data
The benefits of having dedicated package are:
To be clear, this will essentially have no impact on the average user because astropy-iers-data will just get pulled in as a required dependency of astropy.
The slight downside is maintenance of a separate package, but I have set it up so that it will auto-update the data files (as we did in the core package until now) via PRs and we could always enable auto-releasing each time a PR is merged to minimize overhead.
I've set up a simple CI job in astropy-iers-data which runs the astropy.utils.iers tests, though we could also simply run the full astropy test suite.
We should discuss this, but I think we will want to make sure that every time we do a release of astropy-iers-data we should also (and with an automated PR) bump the minimum version of astropy-iers-data in the core package, which will then be equivalent to updating the files here. I also think we might want to use calendar versioning for the astropy-iers-data package since the date is what is most relevant.
Things to do if we want to go ahead:
And in a follow-up PR: