I should have mentioned that we are jumping from 2016b to 2018b. 2016b toolchain is full of inconsistent libraries. Pull requests are automatically checked for duplicates (since a year or so back I think?). The first check-in for a given library wins. This does not sound like it is curated, but this process will keep a toolchain from becoming inconsistent.
From: <[email protected]> on behalf of Mikael Öhman <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Wednesday, August 22, 2018 at 9:21 AM To: "[email protected]" <[email protected]> Subject: Re: [easybuild] 2018b libraries After using easybuild for several years our single largest issue is incompatible libraries used by packages in the same toolchain. We have educated our users to always use modules and to use modules that are in the same toolchain. Workflows can be very complex and users typically load many modules for jobs. Incomparable libraries can easily break scripts. Using rpath should help alleviate issues (though going all the way to removing all LD_LIBRARY_PATHs you are looking into much more intrusive changes) if you want to mix toolchains. There is also an recursive module unloading, which would prevents you from doing some "bad" things with the modules as a user (I have had some bad experiences with this feature though) I feel that the libraries for each toolchain should be set it stone. There should be some easy way to curate the set of libraries. But they are (nowdays)? New modules should stick to the set of libraries currently in the toolchain unless there is a very good reason. Pull requests are automatically checked for duplicates (since a year or so back I think?). Best regards, Mikael
