[SciPy-dev] problems with numpy.setuptools("single_version_externally_managed")
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
>> > (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