Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update version to 4.1.5 #262

Merged
merged 2 commits into from
Oct 8, 2023
Merged

Update version to 4.1.5 #262

merged 2 commits into from
Oct 8, 2023

Conversation

cdce8p
Copy link
Contributor

@cdce8p cdce8p commented Oct 8, 2023

  • Update version to 4.1.5
  • Add changelog entry
  • Split up wheel builder matrix for faster builds
  • Build wheels for MacOS arm64

Ref:

@cdce8p cdce8p mentioned this pull request Oct 8, 2023
@brandon-rhodes brandon-rhodes merged commit 0937c10 into brandon-rhodes:master Oct 8, 2023
4 checks passed
@cdce8p cdce8p deleted the bump-version branch October 8, 2023 19:28
@cdce8p
Copy link
Contributor Author

cdce8p commented Oct 9, 2023

Thanks @brandon-rhodes! The 4.1.5 release does work with Python 3.12 for me.

@brandon-rhodes
Copy link
Owner

brandon-rhodes commented Oct 9, 2023

And thank you for reminding me that the sdist needed to be updated, and not merely new binaries produced! I failed to think through the case of a 3.12 user who needed to build locally.

The cost, alas, is that for the first time there's now a PyEphem release up on PyPI without any wheels for Python 2.7. The last time one of my projects broke 2.7 compatibility, it became clear that it was still in use — there are space-related projects which are still on things like old RHEL versions, and which have locked in their choices of software for the whole mission duration because any upgrade to the underlying operating system could break old scripts or change their output.

I'm not quite clear whether legacy users would now (a) get an error because 4.1.5 lacks a 2.7 binary and they don't have a compiler, or (b) get 4.1.4 installed instead because a 2.7 binary does exist for it.

But since there's a simple quick fix — having them install ephem==4.1.4 — that wouldn't reduce their functionality, because 4.1.5 didn't add any new features or fix any API bugs, I think I'm inclined to do this experiment and see whether any 2.7 users open an issue.

I'm wary of being mean to people like this, and putting a hurdle in front of them (understanding a new error message they might not have seen before, and hoping they discover GitHub, create an account, and open an issue — what if they aren't native English speakers and can't work out those steps?), so there's the chance that in a few days I'll think better of this decision and try fixing the build so that 2.7 artifacts are built again. But as this week and next are busy ones for me, it's likely that it won't happen quickly in any case, and that we will indeed get at least a few-week experiment in whether 2.7 folks are still using PyEphem.

@cdce8p
Copy link
Contributor Author

cdce8p commented Oct 9, 2023

Tbh I didn't realize that the Python 2.7 wheels weren't built. There are still the CI tests for 2.7 though.
I had to check PyPI but the last time wheels were uploaded was for 4.1.1.
https://pypi.org/project/ephem/4.1.1/#files
https://pypi.org/project/ephem/4.1.2/#files

As for pip, AFAIK it shouldn't be an issue. Since 2.7 is still tested, user can install the sdist without issues, even for 4.1.5. They just have to build it themselves. If at some point in the future support were to be removed, that still wouldn't be an issue as long as requires-python is set updated probably. In that case pip would just select the last compatible version.

As for now, since 2.7 is still tested, it was trivial for me to add an additional build step for the release. See #263

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants