-
Notifications
You must be signed in to change notification settings - Fork 1.1k
adopt NEP-29 #828
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
Comments
I think NEP-29 is too aggressive. I'm fine with adopting NEP-29 rules for expected compatibility. But NEP-29 seems to go a step farther and suggest that every downstream project release should only support the prescribed versions regardless of if it's actually necessary. In the specific case above, why should we restrict pvlib to numpy 1.14 when numpy 1.12 and 1.13 will work just as well? I suggest that we instead aggressively drop numpy/python versions when 1. there is a reason to do so and 2. the versions are outside the NEP-29 windows. |
an alternate approach would also be to create a |
better to just bump the requirement. |
Is your feature request related to a problem? Please describe.
the travis-ci test fails for #823 because the minimum NumPy version for py35-min is version 1.10.4 - the
np.roll()
function used was updated to allow multiple axes in NumPy-1.12Describe the solution you'd like
NEP-29 is a proposal by maintainers of IPython, Matplotlib, SciPy, and NumPy that proposes the support window for Python and Numpy.
TL;DR: in the immediate future, drop support for Python-3.5 and Numpy<1.14
Describe alternatives you've considered
np.roll
completelynp.roll
Additional context
Since many other major packages that are used by pvlib are conforming to NEP-29, it makes a lot of sense for pvlib to also conform.
The text was updated successfully, but these errors were encountered: