Conversation
|
Apparently codecov is having connection issues. Anyone with rights willing to bounce the failed build tests? |
tgamblin
left a comment
tgamblin
left a comment
There was a problem hiding this comment.
This is definitely cool, but I have some reservations -- see below.
| # _sp_module_prefix is set by spack --print-sh-vars | ||
| if test "${need_module}" = "yes" ; then | ||
| module() { | ||
| eval `${MODULE_PREFIX}/Modules/bin/modulecmd ${SHELL:=bash} $*` |
There was a problem hiding this comment.
That's a fair comment. It only works with environment-modules, and even then I'm not sure how externally stable it is. That said, it's almost verbatim from the original.
| fi | ||
| if _spack_fn_exists module ; then | ||
| eval orig_"$(declare -f module)" | ||
| function module () { |
There was a problem hiding this comment.
See above w.r.t. #8570 -- I think it has to call module, or at least consider that modulecmd may not be findable.
The other worry I have here is that this won't work for users who load modules after they log in. I've seen users at LC manually source the module initialization scripts long after startup. Now they need to know to source Spack init after module init too. That doesn't seem reliable. The current implementation just ensures that MODULEPATH is set, so modules will pick up Spack stuff even if loaded later.
There was a problem hiding this comment.
That's a fair concern. The main goal is just to make it so that the initial load doesn't have to wait. Really, having a supported mechanism for outputting a set of environment variables that avoids having to call into python (with the agreement that the info may be stale) might be a better way to do this. The mechanism to print out the contents is already there, maybe adding a way to tell this script not to re-compute paths would be more palatable?
| orig_module "$@" | ||
| } | ||
| function ml () { | ||
| module "$@" |
There was a problem hiding this comment.
Is this yours or is this an alias that ships with modules? Wouldn't the module definition handle it already?
There was a problem hiding this comment.
It's an alias that is part of the module profile file. That probably shouldn't stay in, but since the original was providing a bespoke module command, when bootstrapping modules by this script, I added this one for consistency.
|
Relates to #7591 |
3 participants
On a VM with a shared FS, or a system with NFS, this takes setup-env.sh from ~2 seconds to ~ 0.05 seconds (under and over-estimates respectively). It seems like it might be worthwhile to just cache these things given an option, or have a standard location that gets used and cleared, anyway, thoughts on making env loading lazy?