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

Moved ahead with numpy and python versions. #111

Merged
merged 1 commit into from
Apr 2, 2016

Conversation

pelson
Copy link
Member

@pelson pelson commented Apr 2, 2016

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. 😉

@jankatins
Copy link
Contributor

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.

@ocefpaf
Copy link
Member

ocefpaf commented Apr 2, 2016

We will no longer be building py3.4 👎 nor numpy 1.9 👍

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.)

IMO dropping the 32bit windows versions is an easier /less controversial target.

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 😉

@pelson
Copy link
Member Author

pelson commented Apr 2, 2016

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.

@pelson pelson merged commit 62f5d6a into conda-forge:master Apr 2, 2016
@pelson pelson deleted the numpy_up branch April 2, 2016 11:48
@ocefpaf
Copy link
Member

ocefpaf commented Apr 2, 2016

I only have access to a win 32 machine

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.

@jakirkham
Copy link
Member

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.

@ocefpaf
Copy link
Member

ocefpaf commented Apr 2, 2016

I'm worried we are bring NumPy 1.11 online too quickly. With NumPy 1.10 ... Are we sure we aren't introducing problems into our ecosystem by not waiting for those packages to be release?

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 np111 ready.

@jakirkham
Copy link
Member

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.

@msarahan
Copy link
Member

msarahan commented Apr 2, 2016

I have not been involved and can't comment. It does burden the CI
services, but I don't see harm in it otherwise.

On Sat, Apr 2, 2016, 13:42 jakirkham notifications@github.com wrote:

That's not a terrible idea, but am a little worried that we waste CI
cycles on builds that will never work. @msarahan
https://github.com/msarahan, do you have any idea on how the NumPy 1.11
release is proceeding? It would be good to coordinate on this.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#111 (comment)

@jakirkham
Copy link
Member

Do you know who we could talk to in order to get more info?

@msarahan
Copy link
Member

msarahan commented Apr 2, 2016

@ilanschnell makes all the decisions about versions we support.

@ilanschnell
Copy link

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).

@jakirkham
Copy link
Member

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).

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.

6 participants