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

Write a PHEP to describe PyHC's Python & upstream package support policy akin to SPEC 0 #21

Open
namurphy opened this issue Jul 10, 2023 · 6 comments · May be fixed by #29
Open

Write a PHEP to describe PyHC's Python & upstream package support policy akin to SPEC 0 #21

namurphy opened this issue Jul 10, 2023 · 6 comments · May be fixed by #29

Comments

@namurphy
Copy link
Contributor

namurphy commented Jul 10, 2023

We could update the standards to include something akin to NumPy Enhancement Proposal 29 (NEP 29), which states that packages should work on all minor versions of Python released at keast up to 42 months prior and all minor versions of NumPy released at least up to 24 months prior. NEP 29 balances the need for having a well-defined window of supported versions with the need for being able to adopt new language features, depend on newer packages, and reduce maintenance burden. We might consider extending this to include packages like Astropy and the core PyHC packages for our standards.

A consideration is that some missions have a strong need for stability with mission-related software. NEP 29 is a minimum, and nothing would preclude packages from continuing to support older versions of NumPy & Python when there is a need for it.

Update: edited the title to refer to SPEC 0, which has superseded NEP 29.

@namurphy namurphy changed the title Describe Python & upstream package support policy akin to NEP 29 Write a PHEP to describe PyHC's Python & upstream package support policy akin to NEP 29 Apr 2, 2024
@namurphy
Copy link
Contributor Author

namurphy commented Apr 2, 2024

Following up on this...we should write a PHEP! It would be helpful for the heliopythoniverse to be on the same page, especially the core PyHC packages.

It'd also be worth mentioning SPEC 0 which is similar to NEP 29. SPEC 0 recommends that support for Python versions be dropped 36 months after their initial release (in contrast to 42 months in NEP 29) and support for core package dependencies be dropped 24 months after their initial release (though a newer minimum version can be required if there is a critical bugfix).

Another consideration is the status of Python version. At the moment, Python 3.7 is past its end-of-life and Python 3.8 will be EOL in October 2024.

@Cadair
Copy link

Cadair commented Apr 2, 2024

Should be nice and easy "PyHC adopts SPEC-0 in it's entirety" look I wrote it 😜

@sapols
Copy link
Contributor

sapols commented Apr 18, 2024

I fully support this! We currently have that standard that packages should strive to support Python 3 instead of 2. That's clearly outdated. I'd say this new PHEP should replace that standard. SPEC-0 seems well thought out.

I don't really have the cycles the focus on this until after the Summer School, but afterwards I'd like to move forward with this.

@sapols sapols linked a pull request Jun 6, 2024 that will close this issue
5 tasks
@namurphy namurphy changed the title Write a PHEP to describe PyHC's Python & upstream package support policy akin to NEP 29 Write a PHEP to describe PyHC's Python & upstream package support policy akin to SPEC 0 Jun 11, 2024
@jibarnum
Copy link

This is already in progress through @sapols 's work on PHEP 3, yes? Should we close this issue?

@sapols
Copy link
Contributor

sapols commented Sep 11, 2024

@jibarnum note above how it says "linked a pull request on Jun 6 that will close this issue". GitHub will automatically close this issue once PHEP-3 is merged.

@jibarnum
Copy link

ahhhh didn't even notice. thanks @sapols !

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 a pull request may close this issue.

4 participants