Since there was opposition to just removing the output all the time, I've added a new parameter, 'verbosity' that can be set to 0 to hide the output.  This unfortunately requires a bit of code churn and changes the interface to get_info() (but in a backwards-compatible way).


I came up with another option, which is to reuse system_info.verbosity to control whether that output is shown/hidden.  It is already documented as doing so even if that is mostly ignored in the code.

I've made another PR https://github.com/numpy/numpy/pull/4387 to show what I mean.

This would supersede #4081 if accepted.


2013-11-27 13:44 GMT-05:00 Frédéric Bastien <nouiz@nouiz.org>:
Hi,

After more investigation, I found that there already exist a way to
suppress those message on posix system. So I reused it in the PR. That
way, it was faster, but prevent change in that area. So there is less
change of breaking other syste:

https://github.com/numpy/numpy/pull/4081


But it remove the stdout when we run this command:

numpy.distutils.system_info.get_info("blas_opt")

But during compilation, we still have the info about what is found:

atlas_blas_threads_info:
Setting PTATLAS=ATLAS
Setting PTATLAS=ATLAS
customize Gnu95FCompiler
Found executable /usr/bin/gfortran
customize Gnu95FCompiler
customize Gnu95FCompiler using config
compiling '_configtest.c':

/* This file is generated from numpy/distutils/system_info.py */
void ATL_buildinfo(void);
int main(void) {
  ATL_buildinfo();
  return 0;
}

C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -fPIC

compile options: '-c'
gcc: _configtest.c
gcc -pthread _configtest.o -L/usr/lib64/atlas -lptf77blas -lptcblas
-latlas -o _configtest
success!
removing: _configtest.c _configtest.o _configtest
Setting PTATLAS=ATLAS
  FOUND:
    libraries = ['ptf77blas', 'ptcblas', 'atlas']
    library_dirs = ['/usr/lib64/atlas']
    language = c
    define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')]
    include_dirs = ['/usr/include']

  FOUND:
    libraries = ['ptf77blas', 'ptcblas', 'atlas']
    library_dirs = ['/usr/lib64/atlas']
    language = c
    define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')]
    include_dirs = ['/usr/include']

non-existing path in 'numpy/lib': 'benchmarks'
lapack_opt_info:
lapack_mkl_info:
mkl_info:
  libraries mkl,vml,guide not found in
['/opt/lisa/os_v2/common/Canopy_64bit/User/lib', '/usr/local/lib64',
'/usr/local/lib', '/usr/lib64', '/usr/lib']
  NOT AVAILABLE

  NOT AVAILABLE

atlas_threads_info:
Setting PTATLAS=ATLAS
  libraries ptf77blas,ptcblas,atlas not found in
/opt/lisa/os_v2/common/Canopy_64bit/User/lib
  libraries lapack_atlas not found in
/opt/lisa/os_v2/common/Canopy_64bit/User/lib
  libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib64
  libraries lapack_atlas not found in /usr/local/lib64
  libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib
  libraries lapack_atlas not found in /usr/local/lib
  libraries lapack_atlas not found in /usr/lib64/atlas
numpy.distutils.system_info.atlas_threads_info
Setting PTATLAS=ATLAS
Setting PTATLAS=ATLAS
  FOUND:
    libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']
    library_dirs = ['/usr/lib64/atlas']
    language = f77
    define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')]
    include_dirs = ['/usr/include']

  FOUND:
    libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']
    library_dirs = ['/usr/lib64/atlas']
    language = f77
    define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')]
    include_dirs = ['/usr/include']

Frédéric

On Fri, Nov 22, 2013 at 4:26 PM, Frédéric Bastien <nouiz@nouiz.org> wrote:
> I didn't forgot this, but I got side tracked. Here is the Theano code
> I would like to try to use to replace os.system:
>
> https://github.com/Theano/Theano/blob/master/theano/misc/windows.py
>
> But I won't be able to try this before next week.
>
> Fred
>
> On Fri, Nov 15, 2013 at 5:49 PM, David Cournapeau <cournape@gmail.com> wrote:
>>
>>
>>
>> On Fri, Nov 15, 2013 at 7:41 PM, Robert Kern <robert.kern@gmail.com> wrote:
>>>
>>> On Fri, Nov 15, 2013 at 7:28 PM, David Cournapeau <cournape@gmail.com>
>>> wrote:
>>> >
>>> > On Fri, Nov 15, 2013 at 6:21 PM, Charles R Harris
>>> > <charlesr.harris@gmail.com> wrote:
>>>
>>> >> Sure, give it a shot. Looks like subprocess.Popen was intended to
>>> >> replace os.system in any case.
>>> >
>>> > Except that output is not 'real time' with straight Popen, and doing so
>>> > reliably on every platform (cough - windows - cough) is not completely
>>> > trivial. You also have to handle buffered output, etc... That code is very
>>> > fragile, so this would be quite a lot of testing to change, and I am not
>>> > sure it worths it.
>>>
>>> It doesn't have to be "real time". Just use .communicate() and print out
>>> the stdout and stderr to their appropriate streams after the subprocess
>>> finishes.
>>
>>
>> Indeed, it does not have to be, but that's useful for debugging compilation
>> issues (not so much for numpy itself, but for some packages which have files
>> that takes a very long time to build, like scipy.sparsetools or bottleneck).
>>
>> That's a minor point compared to the potential issues when building on
>> windows, though.
>>
>> David
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion