-
-
Notifications
You must be signed in to change notification settings - Fork 189
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
Moved ahead with numpy and python versions. #111
Conversation
IMO py34 should still be build. At least I (windows...) still have situations where there is no 3.5 build for a package (e.g. until yesterday the cartopy package on conda-forge). IMO dropping the 32bit windows versions is an easier /less controversial target. |
I agree with @JanSchulz. Python 3.4 is the Python 3 on Windows right now. Many packages will be missing if we drop that. (I have high hopes that will be false in a month or two.)
Here I am not so sure. Not because we should not drop them eventually, but because it is controversial. In the IOOS channel we had downloads numbers for the 32-bit Windows binaries that were almost as big as the 64-bit. PS: Before someone asks the numbers are based on actual users and not downloads from the page as that has the CIs inflating them 😉 |
Heard you both loud and clear. I've just removed numpy 1.9 and kept py34 for now. We can re-asses in a month or two. Incidentally, I only have access to a win 32 machine, and think there is no way we can remove 32-bit anytime soon AFAIC. |
Many of our users do have Win64 machines but still choose to install 32-bit as that was "recommended practice" on Windows some time ago. |
I'm worried we are bring NumPy 1.11 online too quickly. With NumPy 1.10, it took Continuum about a month to re-release everything that had an ABI dependency to NumPy. Are we sure we aren't introducing problems into our ecosystem by not waiting for those packages to be release? I haven't been following the pulse on this; so, if it is a non-problem feel free to let me know. If we were building the bulk of that stuff here, it might not be such a big deal as to when they adopt it, but as it is I don't think we are ready. |
If we are doing recipes the right way all we are going to get are issues like this. We won't ship broken packages, but well expose what is and what is not |
That's not a terrible idea, but am a little worried that we waste CI cycles on builds that will never work. @msarahan, do you have any idea on how the NumPy 1.11 release is proceeding? It would be good to coordinate on this. |
I have not been involved and can't comment. It does burden the CI On Sat, Apr 2, 2016, 13:42 jakirkham notifications@github.com wrote:
|
Do you know who we could talk to in order to get more info? |
@ilanschnell makes all the decisions about versions we support. |
Anaconda currently supports Python 2.7, 3.4 and 3.5, and NumPy 1.10. We have made NumPy 1.11 available, although not all the packages which depend on a specific NumPy version yet, such as SciPy, pandas, etc. m have been made available yet. Those packages build against NumPy 1.11 we be made available over the next weeks, and the next Anaconda 4.1 will contain NumPy 1.11. Anaconda will continue to support Python 2.7 indefinitely, and we are not planning to drop Python 3.4 support anytime soon (at least till the end of 2016). |
Thanks for the update, @ilanschnell. In light of this, would it be ok if we hold off on NumPy 1.11 and revisit this in a few weeks? We can always re-evaluate if we are ready to support it sooner (i.e. we build or have access to enough NumPy related packages that it isn't a big deal to switch). |
Slightly more controversial this PR. Ping @conda-forge/core as a heads up - this will impact the build matrix of every single feedstock. We will no longer be building py3.4, nor numpy 1.9.
Whilst I appreciate similar arguments can be made for legacy python (2.7), let's not go down that road here - we want conda-forge to be as useful as reasonably possible without the huge burden of carrying around unnecessary versions. 😉