[MRG] Remove BLAS infos from show_versions and build log#14205
[MRG] Remove BLAS infos from show_versions and build log#14205rth merged 13 commits intoscikit-learn:masterfrom
Conversation
| Under Debian-based operating systems, which include Ubuntu:: | ||
| Installing from source without conda or pip requires you to have installed the | ||
| scikit-learn runtime dependencies, Python development headers and a working | ||
| C/C++ compiler. Under Debian-based operating systems, which include Ubuntu:: |
There was a problem hiding this comment.
I'm not sure to get the purpose of this section. It seems to give the dependencies if you want to build without pip or conda. But everywhere else we only explain how to install everything with pip.
There was a problem hiding this comment.
This is to build from source. pip can't install python headers or compilers. If you want to build from source without conda you have to install compiler and headers.
Listing the python packages here is a bit strange, though. I think that is to avoid having to build them, these instructions predate binary wheels.
There was a problem hiding this comment.
So I think part of this can be removed, but we should have instructions on how to build without conda.
There was a problem hiding this comment.
Ok I see. I updated a bit. Let me know what you think
|
Will we still want BLAS details from the scipy installation in order to diagnose efficiency issues?? |
We can get some infos about BLAS from numpy and scipy installations with However we need to be careful with this as it may not always display the right info. I don't know in which situation it can happen... For instance, if I pip install scipy in a conda env, the path in |
|
Does that imply that get_config is buggy?
|
I think For instance, https://stackoverflow.com/a/37190672/1791279 illustrates that there is no easy solution. Maybe this is something threadpoolctl could detect I'm not sure, but for now I think it's OK to merge this as the currently displayed information can be misleading anyway. |
|
(sorry I wrote it wrong, it's |
|
thank's for the explanation. threadpoolctl do detect it. It acts like ldd, so it finds the exact |
| /usr/lib/atlas-base/atlas/libblas.so.3 | ||
| sudo update-alternatives --set liblapack.so.3 \ | ||
| /usr/lib/atlas-base/atlas/liblapack.so.3 | ||
| pip3 install numpy scipy cython |
There was a problem hiding this comment.
Why not installing python3-numpy etc? e.g. on ARM you don't have wheel I think while there are distributions, in which case using the system numpy/scipy makes the most sense.
There was a problem hiding this comment.
Currently this is under installing build dependencies. I don't think installing system numpy scipy is the usual on ubuntu (which is the target of this command). Maybe we can add how to install system numpy scipy cython as an alternative when binary wheels aren't available ?
There was a problem hiding this comment.
The remark of @rth is relevant regarding ARM is relevant. The last time I played with an ARM, I needed to install numpy from python3-numpy to be able to compile scikit-learn from source.
There was a problem hiding this comment.
I added a note to install system dependencies when wheels aren't available
sklearn/utils/_show_versions.py
Outdated
| numpy.show_config() | ||
|
|
||
| print('\nScipy BLAS/LAPACK:') | ||
| scipy.show_config() |
There was a problem hiding this comment.
This prints half a page of text, we don't really want it in issue reports I think? Also, wouldn't it suffer from the same limitations as the previous _get_blas_info ?
There was a problem hiding this comment.
I think show_config is more accurate in general. It's based on infos gathered when building numpy, whereas the previous _get_blas_info takes its infos from numpy.distutils.system_info.get_info which gather infos at run time.
But I'm really not sure how both work so I might be completely wrong...
| /usr/lib/openblas-base/libopenblas.so.0 | ||
| sudo update-alternatives --set liblapack.so.3 \ | ||
| /usr/lib/lapack/liblapack.so.3 | ||
| sudo apt-get install python3-matplotlib |
There was a problem hiding this comment.
why system matplotlib? Seems inconsistent with numpy/scipy above.
| On Red Hat and clones (e.g. CentOS), install the dependencies using:: | ||
|
|
||
| sudo yum -y install gcc gcc-c++ numpy python-devel scipy | ||
| sudo yum -y install gcc gcc-c++ python-devel numpy scipy |
There was a problem hiding this comment.
again, inconsistent with above.
I don't care that much which way we go but we should be consistent. I slightly prefer the pip way.
|
On second thought, I removed numpy/scipy show_config from show_versions. As Roman pointed out, the output is very large and can display a wrong information. Besides, it's not as before when we had a bundled BLAS and we needed to show infos about that. Most issues are not BLAS related, and when we suspect it might be we can ask users to report |
|
I tried to come up to more consistent instructions to install the build dependencies, but I don't know how to update it for centOS. Does anyone can help me with that ? |
glemaitre
left a comment
There was a problem hiding this comment.
Oh I see I did not see the change regarding both system and pip are mentioned.
So LGTM then.
| /usr/lib/lapack/liblapack.so.3 | ||
| sudo apt-get install cython3 python3-numpy python3-scipy python3-matplotlib | ||
|
|
||
| On Red Hat and clones (e.g. CentOS), install the dependencies using:: |
There was a problem hiding this comment.
Maybe add
To use a high performance BLAS library (e.g. OpenBlas) see `scipy installation instructions <https://docs.scipy.org/doc/scipy/reference/building/linux.html>`_.
| .. note:: | ||
|
|
||
| To use a high performance BLAS library (e.g. OpenBlas) see | ||
| `scipy installation instructions <https://docs.scipy.org/doc/scipy/reference/building/linux.html>`_. |
There was a problem hiding this comment.
Added a line break, to keep below 80 char length.
|
Merging. Thanks @jeremiedbb ! |
Fixes #14096
show_versions()