apt-get and/or pip have frequently given me versions of numpy and/or scipy behind what TensorFlow, Theano, Keras etc. want resulting in cryptic errors that don't show up until attempting to run a script.
Yes, that's why people don't use apt-get or pip, and rather install Anaconda.
Pip and wheels are still not really suitable for scientific Python work, because the metadata facilities are not sufficiently rich to capture all the information needed for proper linking of native libraries. By contrast, in Anaconda, things like MKL linkage and Fortran compiler information can be used in the package metadata for dependency solving, to minimize these kinds of compatibility issues.
Interesting and thanks for the summary, seems the motivations are a bit clearer to me now. Is there intention in moving Anaconda's unique features upstream?
Well, kind of. We've tried to work with the python core packaging folks to improve the built-in metadata facilities. (There has been a checkered history there in terms of reception to our ideas...)
In terms of making these packages easier to build, that's really not actually where the problem is. The fact that numpy, scipy, cython, etc. need to have a shared compiler and build toolchain is really a result of operating systems and the C language ABI works.
Pip and wheels are still not really suitable for scientific Python work, because the metadata facilities are not sufficiently rich to capture all the information needed for proper linking of native libraries. By contrast, in Anaconda, things like MKL linkage and Fortran compiler information can be used in the package metadata for dependency solving, to minimize these kinds of compatibility issues.