On 03/04/2017 08:24, Henkel, Andreas wrote:
Dear Easybuilder,
I'm fairly new to easybuild and have just built several packages using the
--try-* options or even adapted easyconfigs. It's a very handy way for
installing software, thanks for that!
Beyond that I had a look at the different module naming schemes and ended up
with using the categorized nms.
I'm a bit surprised about the amount of modules I end up with when installing for example
GCC or Netcdf. We did manual installs before and used System Libs a lot. Now, every lib
ends up being a module and on my first impression this pollutes the module list. I saw
the option hide-deps and filter-deps. Using those would remove some of those libs of
course but as far as I can see it would also take a way some of the "automagic"
since I'd have to specify the options for every install.
You don't have to specify --hide-deps of --filter-deps for every
installations, you can configure EasyBuild via environment variables or
configuration files as well, see
http://easybuild.readthedocs.io/en/latest/Configuration.html .
It is true that you have to gradually build up the list of modules you
want to hide though, since that's a very site-specific aspect.
Note that --filter-deps means something very different than --hide-deps.
With --filter-deps, you're telling EasyBuild not to install something,
and to assume that that particular library/tool is already provided by
the OS (which also means you're at the mercy of the OS a little bit more).
I would like to ask for some hints of experienced easybuild users. How are you
handling the dependent modules? Are they usually hidden-modules or do the users
see all the dependencies in their module environment?
Some sites (e.g. JSC) indeed to quite a bit of effort the only expose
those modules to users that they are actually interested in, and
--hide-deps is a useful way of doing that.
This is being discussed in the HUST-16 workshop paper available at
http://hpcugent.github.io/easybuild/files/eb-jsc-hust16.pdf .
At HPC-UGent, we typically don't hide modules (unless it's a temporary
installation that we want some users to evaluate first), and we're not
getting too much complaints from our users on that to be honest. That
does mean our default 'module avail' view is huge though, but it's less
effort on our part to figure out which modules would be useful to users
and which ones wouldn't be...
regards,
Kenneth
