On 22/08/16 16:09, Joachim Hein wrote:
On 22 Aug 2016, at 15:58, Kenneth Hoste <[email protected]
<mailto:[email protected]>> wrote:
On 22/08/16 15:53, Joachim Hein wrote:
Hi Ward,
Thanks for the swift reaction. So a
scipy-0.17.1-intel-2016b-Python-2.7.12.eb should not be needed,
since the Python module Python-2.7.12-intel-2016b.eb has scipy
0.17.1 in its extension list?
Indeed.
And when scipy 0.18.0 is released, we can install it without touching
the existing Python 2.7.12 installation.
So the only think popping up to me is the mpi4py, if a user needs a
2.0.0 instead of the 1.3.1 inside the Python config. But in general
this should not be a performance issue like e.g. compile netlib blas
vs MKL. Correct?
Indeed, the intention there is to install that mpi4py as a standalone
module, on top of the existing Python 2.7.12 installation.
Via $PYTHONPATH, the mpi4py 2.0.0 installation will have preference
if the module is loaded.
Knowing this earlier might have saved me some time. But it will now
into the future. Should we sort of retire (that is remove) things
like SciPy from the eb-configs?
The current policy is to not remove existing easyconfig files we
included in the central repository.
That is, until we will deprecate a bunch of old toolchains (more on
that later).
Hmm, but is there a way to document (or for me to pick up easily) that
most users should not have the need to build numpy/scipy modules,
since reasonably up-to-date performance versions are included in the
EB python builds? From eb -S so far I didn’t quit get this.
The installed Python module includes a list of extensions (and defines
e.g. $EBEXTSLISTPYTHON), see "module show Python".
We should also enhance the output of "eb" to make it print the extension
name/versions as they are being installed (cfr.
https://github.com/hpcugent/easybuild-framework/issues/1507).
regards,
Kenneth
On 22 Aug 2016, at 15:40, Ward Poelmans <[email protected]
<mailto:[email protected]>> wrote:
On 22-08-16 15:27, Joachim Hein wrote:
Hi,
Looking into e.g. Python-2.7.12-intel-2016b.eb it seems this is
building
stuff like scipy, numpy and mpi4py (sometimes old versions). Why are
the separate easyconfigs for those kind of packages as well? Are the
later obsolete? Someone minds clueing me?
The current policy is to include 'extensions' in the main easyconfig if
they don't require extra dependencies. If they need additional deps, we
create a separate easyconfig. The reason that there something are
separate easyconfigs for mpi4py and such is if we need a newer or older
version then included in the main easyconfig.
Ward
