The module shell function is used to set up the PATH and other environment variables. This cannot be done in an executable because executables run in a sub-process, and environment variables are not inherited “upwards”. Thus, the module command must be a shell function, i.e. a shorthand for a sequence of shell commands. It’s typically enabled either in one of your shell startup scripts (.bashrc or similar), or in a system wide shell startup script.
Its working, I’m not sure, is typically to run an executable which prints the setup to stdout, which is then eval’ed. Things like eval $(ssh-agent), where ssh-agent produces output like SSH_AUTH_SOCK=/tmp/ssh-23224; SSH_AGENT_PID=23223, which is then eval’ed by the shell. The environment variables are inherited by subsequent executables.
Thus, even if you succeed in running module from inside julia via run(`bash -c …`) or similar, it will not, and cannot set environment variables in your julia process. It merely sets things in the bash shell you have run, and which exited before run(...) returned.
What could be possible is to run a shell as a sub-process of julia, with a virtual terminal attached, and forward shell commands to that. It sounds easier to use a shell script for slurm jobs.
It could also be possible to create a julia package for Lmod, it exists for python and R and some other things. Then the module command prints the right syntax to stdout, in julia’s case it would be things like ENV["PATH"] = ...; ENV["WHATEVER"]="what ever". It would be read by julia e.g. like setup=module("load intelcompiler") and eval’ed by julia like eval(Meta.parse(setup)).