On 11/29/2012 10:51 PM, Alex Clark wrote:
Is anyone familiar with this situation enough to comment on it, in a few
sentences? Based on:
-
https://github.com/numpy/numpy/commit/f1a2d6376c430f65550efa235209b86c1a0967e3
It looks like:
- Numpy forked distutils (2001) prior to setuptools existence/popularity
(2004)
- As a result, SciPy users must now pay a terrible price (i.e. SciPy
does not `install_requires` numpy as you might expect; i suspect
because it relies on numpy's distutils… which it can't rely on until
it's installed… which it can't `install_requires` until it's installed…)
I believe numpy.distutils is not a fork as such but extends and
monkey-patches distutils...
The scientific Python community do have problems distributing software
(and hate distutils with a passion), and building SciPy the right way is
something for experts, not newbies.
But while I know the problem you mentioned has come up on the SciPy
list, it really is a trifle in this context. Having to remember to
install NumPy before SciPy is not what people have issues with.
The pain points SciPy deals with are just from a different world. I
think the most common problems are of the sort a) linking with the right
LAPACK in the right way, b) using Fortran compilers with distutils and
in particular combining various Fortran compilers with various C runtime
libraries on Windows.
Going beyond SciPy and just to provide another example, a non-trivial
number of scientific projects use Fortran and Cython and NumPy together;
that's basically unachievable with either distutils or numpy.distutils
or Cython.Distutils (so one uses an actual build tool such as CMake or
scons of waf instead; distutils doesn't really qualify (or was meant to
be) a build tool after all).
Dag Sverre
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
