Blacklisting applications that use the `Conda` easyblock

[ocaisa]

There may be cases where we should refuse to allow the integration of a particular easyconfig. The one that immediately comes to mind is any that use the Conda easyblock. These are almost certain to greatly interfere with the compat layer, as well as being brittle and non-reproducible.

[ocaisa]

https://github.com/easybuilders/easybuild-easyconfigs/pull/18685/files made me think of this, this package includes a massive stack of intrusive software in it's yml file

[boegel]

There's counterexamples too here though, like recent versions of FSL which it seems can only be installed through conda (not from source), see https://github.com/easybuilders/easybuild-easyconfigs/pull/18697

[ocaisa]

I don't think EasyBuild should include FSL like that, it can easily throw so many problems:

• It should be blacklisted as a dependency since you have no idea what the lib directory contains
• How does it work with rpath-ing?
• You shouldn't use it without ensuring you've purged first as it has a high chance of interfering with other software

I would prefer to see something like that built it in a container and include the container.

[boegel]

I didn't spend a lot of time looking into it yet, but it looks like this is basically the only way to install FSL. OK, you could do the install in a container, but that's less user-friendly (or if you expose the container in a way that fsl is a wrapper, I'm not sure it helps much).

[branfosj]

I've been thinking for a while that if we (EasyBuild in general, not ESSSI specfically here) do use Conda for such installs then we should be adding a module conflict (probably on GCCcore) to prevent it being used with anyother part of a module stack.