Issue when EESSI-extend is in the local installation prefix

[casparvl]

After trying the fix for #747 , I installed an EESSI-extend in my local installation prefix.

-------------------------------------- /home/casparl/eessi/versions/2023.06/software/linux/x86_64/amd/zen2/modules/all ---------------------------------------
   EESSI-extend/2023.06-easybuild

Now, I'm getting an issue when module using a new path (which is what EasyBuild's sanity check does - hence all my sanity checks are now failing)

{EESSI 2023.06} [casparl@tcn1 ~]$ module use /tmp/eb-ae4u7ra5/tmpm2ypywjf/all
-- Using /tmp/$USER as a temporary working directory for installations, you can override this by setting the environment variable WORKING_DIR and reloading
the module (e.g., /dev/shm is a common option)
Configuring for use of EESSI_USER_INSTALL under /home/casparl/eessi
-- To create installations for EESSI, you _must_ have write permissions to /home/casparl/eessi/versions/2023.06/software/linux/x86_64/amd/zen2
-- You may wish to configure a sources directory for EasyBuild (for example, via setting the environment variable EASYBUILD_SOURCEPATH) to allow you to reuse
existing sources for packages.
-- Using /tmp/$USER as a temporary working directory for installations, you can override this by setting the environment variable WORKING_DIR and reloading
the module (e.g., /dev/shm is a common option)
Configuring for use of EESSI_USER_INSTALL under /home/casparl/eessi
-- To create installations for EESSI, you _must_ have write permissions to /home/casparl/eessi/versions/2023.06/software/linux/x86_64/amd/zen2
-- You may wish to configure a sources directory for EasyBuild (for example, via setting the environment variable EASYBUILD_SOURCEPATH) to allow you to reuse
existing sources for packages.
-- Using /tmp/$USER as a temporary working directory for installations, you can override this by setting the environment variable WORKING_DIR and reloading
the module (e.g., /dev/shm is a common option)
Configuring for use of EESSI_USER_INSTALL under /home/casparl/eessi
-- To create installations for EESSI, you _must_ have write permissions to /home/casparl/eessi/versions/2023.06/software/linux/x86_64/amd/zen2
-- You may wish to configure a sources directory for EasyBuild (for example, via setting the environment variable EASYBUILD_SOURCEPATH) to allow you to reuse
existing sources for packages.
-- Using /tmp/$USER as a temporary working directory for installations, you can override this by setting the environment variable WORKING_DIR and reloading
the module (e.g., /dev/shm is a common option)
Configuring for use of EESSI_USER_INSTALL under /home/casparl/eessi
-- To create installations for EESSI, you _must_ have write permissions to /home/casparl/eessi/versions/2023.06/software/linux/x86_64/amd/zen2
-- You may wish to configure a sources directory for EasyBuild (for example, via setting the environment variable EASYBUILD_SOURCEPATH) to allow you to reuse
existing sources for packages.
-- Using /tmp/$USER as a temporary working directory for installations, you can override this by setting the environment variable WORKING_DIR and reloading
the module (e.g., /dev/shm is a common option)
Configuring for use of EESSI_USER_INSTALL under /home/casparl/eessi
...
etc, etc

It's not a huge deal: it's actually not trivial to get an EESSI-extend installed in that installation prefix. To install EESSI-extend with EESSI-extend you need to intentionally unset the EBROOTEESSIMINEXTEND variable. Also, except for testing (like me), why would you do this? Nevertheless, I wanted to log it here so that it is findable. And, we might be able to fix it with some safeguard, I'm not sure. I'm not entirely sure how this message is printed, i.e. from where. And why that is triggered when I do a module use of some other path. I think, internally, it might trigger a reload of the modules of the modulepath, which then does something that triggers another reload?

The workaround is simple, of course: remove that module from my local installation prefix.