-
Notifications
You must be signed in to change notification settings - Fork 4
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
Dependency version support plan #40
Comments
Right now, the timeline we can follow is:
Maintaining Python 3.7 for a while longer is unlikely to cause problems so I would propose starting off with Python >= 3.7 and Numpy >= 1.18. I could use some help collecting the versions of our other dependencies. |
Turned out to be a bit more work than I expected. See fatiando/pooch#280 for a working implementation. |
This is done in Pooch and will be official from the 1.6.0 release planned for Jan 2022. |
Done for Boule in fatiando/boule#111 One problem that arose is the lack of binary wheels for Python 3.10 of older versions of numpy (and likely other packages), which means that it can be difficult to install older numpys on the latest Python. So I opted for running the oldest dependencies on the oldest Python and newer dependencies on the newer Python. These are more likely combinations and reduces the size of the CI matrix quite a bit. Besides, asking for the latest numpy in Python 3.6 was producing 1.19 instead of 1.23 because that's the last version with a wheel anyway. |
Following the guidance in fatiando/community#40 and NEP29, support all minor versions from the past 24 months. This means numpy >= 1.19 and attrs >= 19.3. Add CI tests for the oldest versions but test only oldest supported versions with the oldest Python and vice-versa because numpy doesn't supply wheels for old versions on new Python. It also saves CI compute time and should be more than enough of a safeguard.
All our packages now have this implemented. |
Description:
We currently don't really specify the supported versions of many of our dependencies. We've been fine so far but some things are beginning to break, for example the Verde CI has been breaking in Python 3.6 (fatiando/verde#333). I think it's time we adopted a formal policy for dropping older versions of dependencies and implemented testing mechanisms to make sure things work as intended.
Proposal:
I propose we follow NEP 29:
And extend it with:
Implementation:
All projects will need to:
requirements.txt
but also in the conda-forge recipe).>=
in the requirements file with a==
usingsed
.Exceptions:
The only exception I can think of is Pooch, which is used by other libraries and should endeavour to support the minimum Python versions supported by these libraries. We should also be more conservative the number of versions supported of dependencies since we don't want to be the cause of broken environments.
Apply to:
Further instructions:
Related to fatiando/community#XX
We want your help!
We know that maintenance tasks are very demanding, so we don't expect a single person to tackle this issue by themselves. Any help is very welcomed, so please comment below that you want to take care of the changes on any repository and we will assign it to you.
The text was updated successfully, but these errors were encountered: