If that helps somebody, this is the list of our hidden dependencies: EASYBUILD_HIDE_DEPS="ANTLR,APR,APR-util,AT-SPI2-ATK,AT-SPI2-core,ATK,Autoconf,Automake,Bison,CUSP,Coreutils,DB,DBus,DocBook-XML,Dyninst,ETSF_IO,Exiv2,FFmpeg,FLTK,FTGL,GCCcore,GDAL,GEGL,GL2PS,GLEW,GLib,GLPK,GPC,GObject-Introspection,GTI,GTK+,GTS,Gdk-Pixbuf,Ghostscript,GraphicsMagick,GtkSourceView,HarfBuzz,JUnit,JSON-C,JSON-GLib,JasPer,LibTIFF,LibUUID,Libint,LittleCMS,M4,Mesa,NASM,OPARI2,OTF2,PCRE,PDT,PROJ,Pango,PnMPI,PyCairo,PyGObject,Qhull,Qt,Qt5,S-Lang,SCons,SIP,SQLite,SWIG,Serf,Szip,Tcl,Tk,UDUNITS,XML-Parser,XZ,XKeyboardConfig,YAXT,Yasm,adwaita-icon-theme,ant,assimp,babl,binutils,byacc,bzip2,cairo,dbus-glib,damageproto,eudev,expat,g2clib,g2lib,gc,gexiv2,glproto,gperfguile,grib_api,gsettings-desktop-schemas,fixesproto,fontsproto,fontconfig,freeglut,freetype,gettext,icc,ifort,inputproto,intltool,itstool,jhbuild,kbproto,libGLU,libICE,libSM,libX11,libXau,libXaw,libXcursor,libXdamage,libXdmcp,libXext,libXfixes,libXfont,libXft,libXi,libXinerama,libXmu,libXpm,libXrandr,libXrender,libXt,libXtst,libcerf,libcroco,libctl,libdap,libdrm,libdwarf,libelf,libepoxy,libevent,libffi,libfontenc,libgd,libgeotiff,libglade,libidn,libjpeg-turbo,libmatheval,libmypaint,libpng,libpciaccess,libpthread-stubs,libreadline,librsvg,libtool,libunistring,libunwind,libyaml,libxcb,libxkbcommon,libxml2,libxslt,makedepend,motif,ncurses,nettle,nvidia,pixman,pkg-config,pkgconfig,popt,pscom,qrupdate,randrproto,recordproto,renderproto,scrollkeeper,texinfo,util-linux,wxPropertyGrid,wxWidgets,x264,xbitmaps,xcb-proto,xcb-util,xcb-util-image,xcb-util-keysyms,xcb-util-renderutil,xcb-util-wm,xextproto,xineramaproto,xorg-macros,xprop,xproto,xtrans,zlib"
EASYBUILD_HIDE_TOOLCHAINS="GCCcore" Note 2 things: -We hide GCCcore too, but it has to be listed in both EASYBUILD_HIDE_TOOLCHAINS and EASYBUILD_HIDE_DEPS. -You have to be careful when installing a package listed in EASYBUILD_HIDE_DEPS. If you simply install, let’s say, libpng, it won’t be hidden. EasyBuild will hide it just when installed as a dependency, not when installed directly. You’d have to use --hidden in that case. I actually think EB should hide packages by default if listed in EASYBUILD_HIDE_DEPS, but at the moment that’s not the case. Damian On 03/04/17 09:37, "Henkel, Andreas" <[email protected] on behalf of [email protected]> wrote: Dear Kenneth, thank you very much for your explanations! You're right, I oversaw the option of environment variables. I think my issue is the transition from the os-dependent manual install to easybuild, since easybuild tries to the self-contained, hence, I see more modules which were "invisible" because they were os-libs before. Probably, it's just me getting used to it. Then I'll stick with having no hidden modules for now and see if our users adapt. There's another sort of related question I have: Do you also have many redundant modules? I mean, I install GCC 6.3.0, which needed zlib. Later I tried to install some other software with try-toolchain and --use-existing but now I see redundant modules, namely zlib-ver-GCCcore-6.3.0 zlib-ver-foss2017a Although foss2017a uses 6.3.0 in my case. My little experience with try-toolchain is that it somehow ignores existing software/modules. Is that correct or did I do something wrong? Best regards, Andreas -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kenneth Hoste Sent: Monday, April 3, 2017 9:14 AM To: [email protected] Subject: Re: [easybuild] Common config: to hide or not to hide 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 ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------
