ComputeCanada / software-stack-config

8 stars 3 forks source link

Allow defining license paths through envvars #1

Closed ofisette closed 4 years ago

ofisette commented 4 years ago

It would be nice, especially for non-CC sites that may not have write access to the repository, if we could define licenses for restricted software with the corresponding environment variable, rather than having to add that information to /cvmfs/soft.computecanada.ca/config/licenses.

The change proposed here is to consider a license found if the corresponding environment variable was already defined when the search for the license begins. The rest of the search logic remains unchanged. I tested this with MATLAB and the Intel compilers on a local cluster (USask).

mboisson commented 4 years ago

Mmm, that should already work without changes ? If no information is found on /cvmfs, it will not define it, and therefore, if it's defined in the environment variable, it will pick up the license from there.

ofisette commented 4 years ago

Currently, if the env var is set but the license is not otherwise found (by the search logic), the search and define function returns that the license was not found. Therefore, loading the module fails.

mboisson commented 4 years ago

Ah, I see. That however changes the behavior. In particular, it breaks the precedence order that users' local files have priority.

How about instead letting /cvmfs/soft.computecanada.ca/config/licenses being a path that is customizable by sites ?

ofisette commented 4 years ago

A customisable path would work equally well. However, the change I propose does not break precedence order, I think, since the check for the user’s home happens last, is not conditional on license_found, and overrides license_path.

mboisson commented 4 years ago

Ah, true. I thought you were returning as soon as it was defined. I will merge this, but I will not deploy until next week.

mboisson commented 4 years ago

Actually, I think this may break, or at least not cover all cases. The environment variable can be set by some people to be something else than a filename, and in some cases, that file is "sourced". Also, look at the case in /cvmfs/soft.computecanada.ca/easybuild/modules/2017/Core/ansys/2020R1.lua

where it's not the same environment variable that is used.

ofisette commented 4 years ago

I do not understand why that would make any difference. If the module expects or allows something other than a filename, the variable can simply be set accordingly, e.g. the file pointed to could be a source-able script. I also fail to see what is special with the Ansys module. It just seems to me that the variable to set is __ANSYS_LICENSE_FILE.

However, I have not checked all modules, and if we suspect this could be a breaking change, then we could have a separate license directory instead, something like an optional RSNT_LICENSE_PATH. Should I make a patch for that instead?

mboisson commented 4 years ago

The risk is that find_and_define_license_file is supposed to return a filename, whereas the environment variable could be defined in the form of <server>@port.

Some modules will execute the "file" that is returned. This is the case for ansys and abaqus. That is because they define two environment variables rather than one.

Obviously, trying to read and source <server>@port as if it were a file will fail. I don't think any module would actually break because we were careful to not actually use the same environment variable in those cases. However, returning the content of an environment variable can break the expectation that this function returns a file path.

mboisson commented 4 years ago

Supporting RSNT_LOCAL_LICENSE_PATH would be safer in that regard.