[SciPy-dev] problems with numpy.setuptools...

[Pearu Peterson]

Robert Kern wrote:
> David Cournapeau wrote:
>> Perry Greenfield wrote:
>>> On Sep 25, 2007, at 11:43 AM, David M. Cooke wrote:
>>>
>>>   
>>>> "Pearu Peterson" <pearu at cens.ioc.ee> writes:
>>>>     
>>>>> On Tue, September 25, 2007 5:57 pm, David M. Cooke wrote:
>>>>>       
>>>>>> $ python setupegg.py bdist_egg
>>>>>> Running from numpy source directory.
>>>>>> ********************************************************
>>>>>> WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!
>>>>>> [etc.]
>>>>>>         
>>>>> This is a warning message. It does not break code.
>>>>>       
>>>> When a supported method of building throws up a huge warning, I
>>>> consider that broken ;-)
>>>>     
>>> Let me echo this. I'm not sure what all the recent discussion on the  
>>> fixes has left this particular issue but I think there needs to be  
>>> some way to deal with this (either a way to suppress the message or  
>>> handle things differently). This kind of warning is not going to be  
>>> helpful to those that download software that uses numpy. They won't  
>>> know what it means and won't know what to do about it.
>>>   
>> While I agree with you, AFAIK, this appears only in svn. If you download 
>> from svn, you are accepting the higher possibility of something being 
>> broken, in my opinion.
> 
> Well yes, but eventually we will cut a release. If we don't think the warning
> should be in the release, we should remove it from SVN.

I think issuing such warnings is useful for developers as
quite often one writes a code into a big system without being
able to test the code with all practical corner cases.
numpy.distutils is an example.

So, this kind of a warning is like a mild assertion failure
that should draw other developers attention that the code
might do (or not do) something that is different what they
have assumed. But the code will still run. If nobody will see
the warning, then the new code is (may be) safe. If other developers
see the warning then that means that they should work together
to remove the cause of possible issues from the start.

Given issue is a prefect example of this kind of situation
that captures possible problems in the development state
rather than from users feedback that may have very long
time span.

I think we should practice this kind of warnings more often.

When making a release, such warnings should be disabled
(read: removed when the issue is resolved).

Pearu