brandon-rhodes / python-sgp4

Python version of the SGP4 satellite position library
MIT License
376 stars 88 forks source link

2.23 not released on pypi #124

Closed jochym closed 12 months ago

jochym commented 1 year ago

The latest version on PyPi is still 2.22. This blocks conda-forge build for py3.12 Please, @brandon-rhodes take a look.

brandon-rhodes commented 1 year ago

Thanks for the reminder! The GitHub CI failed for the new version, it looks like because of a NumPy build problem:

https://github.com/brandon-rhodes/python-sgp4/actions/runs/6367198035/job/17286010419#step:7:1458

Now that some time has passed, I'll go re-run that build and see if the results are any better. I'll report back here.

brandon-rhodes commented 1 year ago

@jochym — Do you know whether 3.12 is usable yet on GitHub? Adding it to the package test matrix results in an error:

https://github.com/brandon-rhodes/python-sgp4/actions/runs/6807695212/job/18510972803

[build_test_dist (‘3.12.0’, ubuntu-latest)]

Run actions/setup-python@v3
Version ‘3.12.0’ was not found in the local cache
Error: Version ‘3.12.0’ with arch x64 not found
The list of all available versions can be found here: https://raw.githubusercontent.com/actions/python-versions/main/versions-manifest.json

And yet when I follow that link, the json file has an entry:

  {
    "version": "3.12.0",
    "stable": true,
    "release_url": "https://github.com/actions/python-versions/releases/tag/3.12.0-6381888192",
    "files": [...

I have tried both the names ‘3.12' and '3.12.0’. Any ideas?

jochym commented 1 year ago

Maybe not yet. The 3.12 is functional in the conda-forge pipeline. Maybe you can drop 3.12 from the test matrix for now and release it that way, and it will be tested in the conda-forge pipeline? For now the previous version bumps on the Regexp -> Regex change in the python test framework.

brandon-rhodes commented 1 year ago

@mworion — Do you have any insight into the failure of the build_test_wheels step in this project’s latest GitHub Actions? Examples are:

https://github.com/brandon-rhodes/python-sgp4/actions/runs/6367198035 https://github.com/brandon-rhodes/python-sgp4/actions/runs/6812329103/job/18524507638#step:7:1503

I have not yet been able to tell exactly what is going on. And, as I think it's that Actions step that builds the project so that it can be uploaded to PyPI, I think this blocks our ability to do any package releases for now?

Thanks for any insight you might be able to provide!

brandon-rhodes commented 1 year ago

Ah — it looks like the problem is with NumPy.

https://github.com/numpy/numpy/issues/24703

But they have repented of having broken so many builds, and are reverting the change in the next version:

https://github.com/numpy/numpy/pull/25063

To avoid having to wait for the next NumPy release, I'll see if I can pin our build to the previous version.

mworion commented 1 year ago

@brandon-rhodes, sure looking into. It's a topic from numpy, I already have a setup running for python 3.12. I currently checking how complicated the solution would be to keep 32bit in lower (3.7-3.9) python versions as we have to 64bit only on actual numpy solutions. I would prepare a PR as soon I have a resonable solution, but this should be ready within next days: see local solution https://github.com/mworion/python-sgp4/actions/runs/6790322192

Michel

Edit: Numpy is needed for testing and in the build matrix not all dependencies could be solved, so the action tries to build numpy from source and runs into to BLAS topic. Basically no need to compile numpy from source, but just another handling of dependencies in build action.

brandon-rhodes commented 1 year ago

@mworion — Amazing! How did you figure out all of those configuration changes? It would have taken me a long time to work out all of those adjustments, and you did it in just a few hours!

There's one last hurdle — the actual publishing step failed for the new version?

https://github.com/brandon-rhodes/python-sgp4/actions/runs/6819220684/job/18546658852

I can check the error in more detail this weekend if you are not sure what to try next. Thanks so much for getting us this far!

mworion commented 12 months ago

@brandon-rhodes : I take a look to this.

brandon-rhodes commented 12 months ago

Your fix worked! Version 2.23 is out! Thanks so much for heroically jumping into a project you haven't even touched since early 2022, and within hours having fixes for obscure GitHub Actions problems. With a conference this coming week that I'm busy preparing for, I would not have had time to work through these problems. It's because of you that sgp4 now supports Python 3.12 for the community!

@jochym — As 2.23 is now on PyPI, I'm going to close this issue, but please comment further if you see any last snags with the release.

jochym commented 12 months ago

@brandon-rhodes unfortunately we still have a problem on pypy7.3 (python 3.9). The Doctest in this variant gives errors.

On linux :

Doctest: sgp4 ... *** Error in `python': corrupted double-linked list: 0x0000558f6fd00990 ***

On windows:


    [[0 0 0 0]
     [0 0 0 0]]
Got:
    []
----------------------------------------------------------------------
File "D:\bld\sgp4_1699718927102\_test_env\lib\site-packages\sgp4\__init__.py", line 289, in sgp4
Failed example:
    print(r)
Expected:
    [[[-3431.31  2620.15 -5252.97]
      [-3478.86  2575.14 -5243.87]
      [-3526.09  2529.89 -5234.28]
      [-3572.98  2484.41 -5224.19]]
    <BLANKLINE>
     [[ 5781.85  2564.   -2798.22]
      [ 5749.36  2618.59 -2814.63]
      [ 5716.35  2672.94 -2830.78]
      [ 5682.83  2727.05 -2846.68]]]
Got:
    []
----------------------------------------------------------------------
File "D:\bld\sgp4_1699718927102\_test_env\lib\site-packages\sgp4\__init__.py", line 299, in sgp4
Failed example:
    print(v)
Expected:
    [[[-5.52 -5.19  1.02]
      [-5.49 -5.22  1.08]
      [-5.45 -5.25  1.14]
      [-5.41 -5.28  1.2 ]]
    <BLANKLINE>
     [[-3.73  6.33 -1.91]
      [-3.79  6.3  -1.88]
      [-3.85  6.28 -1.85]
      [-3.91  6.25 -1.83]]]
Got:
    []

On OSX:

Doctest: sgp4 ... /Users/runner/miniforge3/conda-bld/sgp4_1699718850252/test_tmp/run_test.sh: line 7:  4838 Abort trap: 6

The tests re here: https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=822145&view=results

I can (and temporarily will) block this variant (pypy7.3/py3.9) but it may indicate some deeper problem in the code.

brandon-rhodes commented 12 months ago

Interesting! I probably won't be able to dig in this week, but I'll keep in mind that pypy isn't entirely happy with the library.

jochym commented 12 months ago

No. There is only pypy7.3 3.9 for now (AFAIK) in conda-forge. The pypy itself also supports 3.10.

jochym commented 12 months ago

The 2.23 is built for all cpythons (up to 3.12) in conda-forge. pypy is blocked for now.

brandon-rhodes commented 12 months ago

Thank you for the update!

Do the Conda servers have any stats on whether sgp4 has any pypy users? I have never heard of any, but maybe there are server stats that could reveal whether there are folks on pypy who use the library. (Since the only purpose of this release was to support 3.12, I suppose the previous release will work perfectly well for pypy users and will return the same results the current version would?)

jochym commented 12 months ago

The statistics are visible on the anaconda page: https://anaconda.org/conda-forge/sgp4/files Anaconda-Server Badge Anaconda-Server Badge

Unfortunately, (or fortunately) there is no separate package for pypy, so there is no separate stats. The first version built for pypy was 2.21, and we have checks report for rebuild with 3.11 in the matrix (https://github.com/conda-forge/sgp4-feedstock/pull/41), the logs are purged though. The last automerged build is: https://github.com/conda-forge/sgp4-feedstock/pull/42 with builds for (e.g.) numpy1.21python3.9.____73_pypy.

brandon-rhodes commented 11 months ago

Well, that's unfortunate — it is hard to know whether to support a platform, if the install server doesn't give us stats about which platforms' wheels are being downloaded. For now, let's ignore this maybe-insoluble error, and if any pypy folks want to use sgp4 with pypy then they can jump in and maybe volunteer help with debugging this later.