Example of Python-core at GCCcore/7.3.0 with Python at intel/2018b

[Micket]

I created this PR by modifying #6479 to exemplify how I think we should split Python-core and Python. I have built this, and it does work great. There was a single numpy test that failed, though, the build was accepted anyway (perhaps it's know to fail?). There definitely doesn't seem to be anything to to worry about having a libpython+interpreter built with gcc and a numpy/scipy build with icc.

1. Nothing fancy, no hidden packages, no shadowing (so no ABI worries)
2. No duplicated packages (even more important as more toolchains of various pop up, iomkl, goolfc, cuda, and all the other permutations of the usual suspects. So a lot less stuff to compile.
3. Removes the need for a Python-*-bare
4. Most critically; will allow us to move even more dependencies to GCCcore;
   Mesa, Tkinter, PyGTK, PyQt, Tk, Swig, etc. etc. etc.

So this means a lot less work maintaining easyconfigs, a lot less stuff to (re-)compile, and vastly larger module availability in less popular toolchains,

I'm not really very concerned how the configs are implemented. We can have numpy/scipy/pandas as a standalone config, doesn't matter. But I can't see any reason why at least the interpreter and libpython wouldn't exclusively be built at GCCcore.
I fail to see any downside to this. If there is a critical piece of information I have managed to neglect, please let me know.

[boegel]

@Micket Can you sync your branch with current develop now #6479 is merged?

@damianam Thoughts on this approach?

[Micket]

@boegel Rebase done. I'll see if I can figure out why pandas didn't build for me.
(this PR just contains the intel version, because the intel-gcc mix is the only thing, if this works, then I would naturally add the equivalent foss version)
I also don't know if a "Bundle" is the right option here, I had to mess about with PYTHONPATH for scipy to pick up numpy during installation (i suppose this is close to what EB_Python does).

[boegel]

@Micket Seems like you need the latest pandas version for Python 3.7.0, cfr. https://pandas.pydata.org/pandas-docs/version/0.23.2/whatsnew.html

[boegel]

Ah, wait, this is Python 2.7.15, so that pandas update may not help you.

What kind of build issue did you run into?

[Micket]

@boegel It seems that when building the pandas package, gcc is picked up as the linker, which then doesn't recognize the icc specific flags

creating build/temp.linux-x86_64-2.7/pandas/io/sas
icc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -O2 -xHost -ftz -fp-speculation=safe -fp-model source -fPIC -I/apps/Hebbe/software/MPI/intel/2018.3.222-GCC-7.3.0-2.30/impi/2018.3.222/imkl/2018.3.222/mkl/include -fPIC -Ipandas/_libs/src/klib -Ipandas/_libs/src -I/apps/Hebbe/software/MPI/intel/2018.3.222-GCC-7.3.0-2.30/impi/2018.3.222/Python/2.7.15/lib/python2.7/site-packages/numpy-1.14.5-py2.7-linux-x86_64.egg/numpy/core/include -I/apps/Hebbe/software/Compiler/GCCcore/7.3.0/Python-core/2.7.15/include/python2.7 -c pandas/io/sas/sas.c -o build/temp.linux-x86_64-2.7/pandas/io/sas/sas.o -Wno-unused-function
In file included from /apps/Hebbe/software/MPI/intel/2018.3.222-GCC-7.3.0-2.30/impi/2018.3.222/Python/2.7.15/lib/python2.7/site-packages/numpy-1.14.5-py2.7-linux-x86_64.egg/numpy/core/include/numpy/ndarrayobject.h(18),
                 from /apps/Hebbe/software/MPI/intel/2018.3.222-GCC-7.3.0-2.30/impi/2018.3.222/Python/2.7.15/lib/python2.7/site-packages/numpy-1.14.5-py2.7-linux-x86_64.egg/numpy/core/include/numpy/arrayobject.h(4),
                 from pandas/io/sas/sas.c(566):
/apps/Hebbe/software/MPI/intel/2018.3.222-GCC-7.3.0-2.30/impi/2018.3.222/Python/2.7.15/lib/python2.7/site-packages/numpy-1.14.5-py2.7-linux-x86_64.egg/numpy/core/include/numpy/ndarraytypes.h(84): warning #2650: attributes ignored here
                      NPY_CHAR NPY_ATTR_DEPRECATE("Use NPY_STRING"),
                               ^

In file included from /apps/Hebbe/software/MPI/intel/2018.3.222-GCC-7.3.0-2.30/impi/2018.3.222/Python/2.7.15/lib/python2.7/site-packages/numpy-1.14.5-py2.7-linux-x86_64.egg/numpy/core/include/numpy/ndarraytypes.h(1816),
                 from /apps/Hebbe/software/MPI/intel/2018.3.222-GCC-7.3.0-2.30/impi/2018.3.222/Python/2.7.15/lib/python2.7/site-packages/numpy-1.14.5-py2.7-linux-x86_64.egg/numpy/core/include/numpy/ndarrayobject.h(18),
                 from /apps/Hebbe/software/MPI/intel/2018.3.222-GCC-7.3.0-2.30/impi/2018.3.222/Python/2.7.15/lib/python2.7/site-packages/numpy-1.14.5-py2.7-linux-x86_64.egg/numpy/core/include/numpy/arrayobject.h(4),
                 from pandas/io/sas/sas.c(566):
/apps/Hebbe/software/MPI/intel/2018.3.222-GCC-7.3.0-2.30/impi/2018.3.222/Python/2.7.15/lib/python2.7/site-packages/numpy-1.14.5-py2.7-linux-x86_64.egg/numpy/core/include/numpy/npy_1_7_deprecated_api.h(15): warning #1224: #warning directive: "Using deprecated NumPy API, disable it by "          "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
  #warning "Using deprecated NumPy API, disable it by " \
   ^

gcc -shared -L/apps/Hebbe/software/Core/GCCcore/7.3.0/lib64 -L/apps/Hebbe/software/Core/GCCcore/7.3.0/lib -L/apps/Hebbe/software/Compiler/GCCcore/7.3.0/bzip2/1.0.6/lib -L/apps/Hebbe/software/Compiler/GCCcore/7.3.0/zlib/1.2.11/lib -L/apps/Hebbe/software/Compiler/GCCcore/7.3.0/libreadline/7.0/lib -L/apps/Hebbe/software/Compiler/GCCcore/7.3.0/ncurses/6.1/lib -L/apps/Hebbe/software/Compiler/GCCcore/7.3.0/SQLite/3.24.0/lib -L/apps/Hebbe/software/Compiler/GCCcore/7.3.0/GMP/6.1.2/lib -L/apps/Hebbe/software/Compiler/GCCcore/7.3.0/binutils/2.30/lib -L/apps/Hebbe/software/Core/icc/2018.3.222-GCC-7.3.0-2.30/lib/intel64 -L/apps/Hebbe/software/MPI/intel/2018.3.222-GCC-7.3.0-2.30/impi/2018.3.222/imkl/2018.3.222/lib -L/apps/Hebbe/software/MPI/intel/2018.3.222-GCC-7.3.0-2.30/impi/2018.3.222/imkl/2018.3.222/mkl/lib/intel64 -L/apps/Hebbe/software/MPI/intel/2018.3.222-GCC-7.3.0-2.30/impi/2018.3.222/imkl/2018.3.222/lib -O2 -xHost -ftz -fp-speculation=safe -fp-model source -fPIC -I/apps/Hebbe/software/MPI/intel/2018.3.222-GCC-7.3.0-2.30/impi/2018.3.222/imkl/2018.3.222/mkl/include build/temp.linux-x86_64-2.7/pandas/io/sas/sas.o -L/apps/Hebbe/software/Compiler/GCCcore/7.3.0/Python-core/2.7.15/lib -lpython2.7 -o build/lib.linux-x86_64-2.7/pandas/io/sas/_sas.so
gcc: error: source: No such file or directory
gcc: error: unrecognized command line option ‘-ftz’; did you mean ‘-flto’?
gcc: error: unrecognized command line option ‘-fp-speculation=safe’
gcc: error: unrecognized command line option ‘-fp-model’
error: command 'gcc' failed with exit status 1
 (at easybuild/tools/run.py:501 in parse_cmd_output)
== 2018-07-07 13:08:36,159 easyblock.py:2778 WARNING build failed (first 300 chars): cmd " /apps/Hebbe/software/Compiler/GCCcore/7.3.0/Python-core/2.7.15/bin/python setup.py build " exited with exit code 1 and output:

easybuild-Python-2.7.15-pandas_failed.log

[Micket]

@boegel So, I found a fix by setting

export LDSHARED="icc -shared"

into prebuildopts.

Not ideal, as this would then be required to be added for every other pythonpackage-easyconfig compiled with icc, but still a small tradeoff for the benefits of a Python-core I.M.H.O.
Alternatively, EB_PythonPackage, numpy, scipy, can add LDSHARED to their respective blocks.

I'm not sure how the default value gets set;

module load GCCcore/7.3.0 Python-core
python -c "from distutils import sysconfig; print(sysconfig.get_config_var('LDSHARED'))"

but it might also be possible that another fix is to keep setuptools (and Cython) at the intel/foss level (unless this is actually set when compiling Python).

I think setting LDSHARED in EB_PythonPackage is a reasonable approach.

[Micket]

Tested easybuilders/easybuild-easyblocks#1455 so if that is accepted, we can drop the prebuildopts in these configs.

[Micket]

Attempting to redo this for Python 3 (for our local installation), I got hit with a limitation in PythonPackage, which looks for the interpreter via

python_root = get_software_root('Python')

and, since the package was now called Python-core, this fails. While for Python-core-2.7.* this happens to work out anyway, it's probably prudent to have the PythonPackage block look for Python-core, if we go with an approach like this.

[damianam]

@Micket I agree. I think it makes sense to check where the python executable comes from, and extrapolate python_root from it. Then you are free to call your python whatever you want. Let's say you install Intel's python distribution under the name Python-Intel. As things are now, the easyblock would fail in this case again. Single'ing out every exception seems like a bad decision to me.

[Micket]

This PR has outlived it's usefulness (and this approach isn't that good)