On Sun, 27 Mar 2005, Michiel Jan Laurens de Hoon wrote:
> Having a separate scipy_distutils that fixes some bugs in Python's distutils
> is a design mistake in SciPy that we should not repeat in Numeric3. Not that
> I don't think the code in scipy_distutils is not useful -- I think it would
> be very useful. But the fact that it is not integrated with the existing
> Python distutils makes me wonder if this package really has been thought out
> that well.
I don't think that part of scipy_distutils design was to fix Python's
distutils bugs. As we found a bug, its fix was added to scipy_distutils as
well as reported to distutils bug tracker. The main reason for adding bug
fixes to scipy_distutils was to continue the work with scipy instead of
waiting for the next distutils release (i.e. Python release), nor we could
expect that SciPy users would use CVS version of Python's distutils. Also,
SciPy was meant to support Python 2.1 and up, so the bug fixes remained
relevant even when the bugs were fixed in Python 2.2 or 2.3 distutils.
So much of history..
> As far as I can tell, scipy_distutils now fulfills four functions:
> 1) Bug fixes for Python's distutils for older Python versions. As Numeric3
> will require Python 2.3 or up, these are no longer relevant.
> 2) Bug fixes for current Python's distutils. These should be integrated with
> Python's distutils. Writing your own package instead of contributing to
> Python gives you bad karma.
> 3) Fortran support. Very useful, and I'd like to see them in Python's
> distutils. Another option would be to put this in SciPy.fortran or something
> similar. But since Python's distutils already has a language= option for C++
> and Objective-C, the cleanest way would be to add this to Python's distutils
> and enable language="fortran".
> 4) Stuff particular to SciPy, for example finding Atlas/Lapack/Blas
> libraries. These we can decide on a case-by-case basis if it's useful for
> Numeric3.
Plus I would add the scipy_distutils ability to build sources on-fly
feature (build_src command). That's a very fundamental feature useful
whenever swig or f2py is used, or when building sources from templates or
dynamically during a build process.
Btw, I have started scipy_core clean up. The plan is to create the
following package tree under Numeric3 source tree:
scipy.distutils - contains cpuinfo, exec_command, system_info, etc
scipy.distutils.fcompiler - contains Fortran compiler support
scipy.distutils.command - contains build_src and config_compiler
commands plus few enhancements to build_ext, build_clib, etc
commands
scipy.base - useful modules from scipy_base
scipy.testing - enhancements to unittest module, actually
current scipy_test contains one useful module (testing.py) that
could also go under scipy.base and so getting rid of scipy.testing
scipy.weave -
scipy.f2py - not sure yet how to incorporate f2py2e or weave sources
here. As a first instance people are assumed to download them to
Numeric3/scipy/ directory but in future their sources could be added
to Numeric3 repository. For Numeric3 f2py and weave are optional.
scipy.lib.lapack - wrappers to Atlas/Lapack libraries, by default
f2c generated wrappers are used as in current Numeric.
For backwards compatibility, there will be
Packages/{FFT,MA,RNG,dotblas+packages from numarray}/
and
Lib/{LinearAlgebra,..}.py
under Numeric3 that will use modules from scipy.
Pearu