[SciPy-dev] problems with numpy.setuptools("single_version_externally_managed")

Pearu Peterson pearu@cens.ioc...
Wed Sep 26 03:29:45 CDT 2007

David Cournapeau wrote:
> Pearu Peterson wrote:
>>> I am just a bit afraid that modifying runtime objects 
>>> both in numpy.distutils and setuptools will cause other problems in the 
>>> near future 
>> There will be problems for sure and we are fixing them gradually as they
>> appear - that is a normal process.
>> Since we as stuck to distutils then we don't have alternatives to
>> these kind of fixes.
> Isn't it possible to use a subclass instead of modifying the existing one ?

It is possible. But in the given case it's not reasonable. Either we 
have few lines of code or we have lots of code replication that needs to
be maintained.

>>  > (my impression is that it is safe to assume setuptools will
>>> become part of the standard library in python at some point, and we will 
>>> have to cope with it).
>> Note that we are currently supporting python versions starting from 2.3.
>> I don't know if setuptools is a part of python 2.6 already but
>> even then we need to keep distutils support until we drop support
>> for python 2.5. I bet this will not happen in the coming 5 years
>> at least.
> Sure, I've never implied to use setuptools only or to stop depending on 
> distutils, just that it may be better to avoid modifying distutils on 
> the fly when possible to avoid friction with setuptools as much as possible.

I agree on saying that modifying packages on the fly is always hackish 
and should be discoraged. I disagree on prefering setuptools over
distutils for practical reasons. If both setuptools and numpy.distutils
overwrite the same functionality in distutils then these overwrites
should be syncronized.  i guess we need to support building scipy/numpy 
with both sets of tools: setuptools and numpy.distutils.


More information about the Scipy-dev mailing list