Skip to content

also consider $LMOD_CMD in bootstrap script#1736

Merged
boegel merged 1 commit intoeasybuilders:developfrom
boegel:bootstrap_LMOD_CMD
Apr 26, 2016
Merged

also consider $LMOD_CMD in bootstrap script#1736
boegel merged 1 commit intoeasybuilders:developfrom
boegel:bootstrap_LMOD_CMD

Conversation

@boegel
Copy link
Copy Markdown
Member

@boegel boegel commented Apr 22, 2016

No description provided.

@boegel boegel added this to the v2.8.0 milestone Apr 22, 2016
@boegel
Copy link
Copy Markdown
Member Author

boegel commented Apr 22, 2016

@verdurin: please test?

@hpcugentbot
Copy link
Copy Markdown

EasyBuild framework unit test suite PASSed (see https://jenkins1.ugent.be/job/easybuild-framework-pr-builder/2962/console for more details).

This pull request is now ready for review/testing.

Please try and find someone who can tackle this; contact @boegel if you're not sure what to do.

@verdurin
Copy link
Copy Markdown
Member

@boegel: the bootstrapping works:

[[INFO]] Found module command '/usr/share/lmod/lmod/libexec/lmod' via $LMOD_CMD (Lmod), so using it.

and I'm able to load EB. However, when I run it there's an error:

[vagrant@localhost eb]$ eb -S SAMtools
== temporary log file in case of crash /tmp/eb-TxN07l/easybuild-0eecm7.log
== Searching (case-insensitive) for 'SAMtools' in /home/vagrant/.local/easybuild/software/EasyBuild/2.7.0/lib/python2.7/site-packages/easybuild_easyconfigs-2.7.0-py2.7.egg/easybuild/easyconfigs
CFGS1=/home/vagrant/.local/easybuild/software/EasyBuild/2.7.0/lib/python2.7/site-packages/easybuild_easyconfigs-2.7.0-py2.7.egg/easybuild/easyconfigs
 * $CFGS1/b/BSMAP/BSMAP-2.74_samtools-deps.patch
 * $CFGS1/s/SAMtools/SAMtools-0.1.18-goalf-1.1.0-no-OFED.eb
 * $CFGS1/s/SAMtools/SAMtools-0.1.18-goolf-1.4.10.eb
 * $CFGS1/s/SAMtools/SAMtools-0.1.18-ictce-4.0.6.eb
 * $CFGS1/s/SAMtools/SAMtools-0.1.18-ictce-5.3.0.eb
 * $CFGS1/s/SAMtools/SAMtools-0.1.19-foss-2015a.eb
 * $CFGS1/s/SAMtools/SAMtools-0.1.19-goolf-1.4.10.eb
 * $CFGS1/s/SAMtools/SAMtools-0.1.19-goolf-1.7.20.eb
 * $CFGS1/s/SAMtools/SAMtools-0.1.19-ictce-5.5.0.eb
 * $CFGS1/s/SAMtools/SAMtools-0.1.19-intel-2015a.eb
 * $CFGS1/s/SAMtools/SAMtools-0.1.19_Makefile-ncurses.patch
 * $CFGS1/s/SAMtools/SAMtools-0.1.20-goolf-1.7.20.eb
 * $CFGS1/s/SAMtools/SAMtools-0.1.20-intel-2015b.eb
 * $CFGS1/s/SAMtools/SAMtools-0.1.20_Makefile-ncurses.patch
 * $CFGS1/s/SAMtools/SAMtools-1.1-foss-2014b.eb
 * $CFGS1/s/SAMtools/SAMtools-1.1-goolf-1.4.10.eb
 * $CFGS1/s/SAMtools/SAMtools-1.1-intel-2014b.eb
 * $CFGS1/s/SAMtools/SAMtools-1.1-intel-2015a.eb
 * $CFGS1/s/SAMtools/SAMtools-1.1_Makefile.patch
 * $CFGS1/s/SAMtools/SAMtools-1.2-foss-2015a-HTSlib-1.2.1.eb
 * $CFGS1/s/SAMtools/SAMtools-1.2-foss-2015a.eb
 * $CFGS1/s/SAMtools/SAMtools-1.2-foss-2015b.eb
 * $CFGS1/s/SAMtools/SAMtools-1.2-goolf-1.4.10.eb
 * $CFGS1/s/SAMtools/SAMtools-1.2-goolf-1.7.20.eb
 * $CFGS1/s/SAMtools/SAMtools-1.2-intel-2015a-HTSlib-1.2.1.eb
 * $CFGS1/s/SAMtools/SAMtools-1.2-intel-2015b-HTSlib-1.2.1.eb
 * $CFGS1/s/SAMtools/SAMtools-1.2_extHTSlib_Makefile.patch
 * $CFGS1/s/SAMtools/SAMtools-1.3-foss-2015b.eb
 * $CFGS1/s/SAMtools/SAMtools-1.3-foss-2016a.eb
 * $CFGS1/s/SAMtools/SAMtools-1.3-intel-2016a.eb
 * $CFGS1/s/SAMtools/SAMtools-1.3_Makefile.patch
 * $CFGS1/s/SAMtools/SAMtools_Makefile-ncurses.patch
ERROR: EnvironmentModulesC modules tool can not be used, 'modulecmd' command is not available.

@boegel
Copy link
Copy Markdown
Member Author

boegel commented Apr 26, 2016

@verdurin Thanks for the confirmation.

The runtime problem you run into is because the default setting for the modules tool is to use modulecmd (i.e. the Tcl/C environment modules implementation).

I'm not sure if we want to change the default to something more dynamic...

For the bootstrap, it's fine, since it doesn't affect the end result: the installation and generated module file are exactly the same, regardless of the module tool being used.

However, if both modulecmd and lmod (or $LMOD_CMD) are available in the environment, I wouldn't want eb to pick one over the other randomly...

@boegel
Copy link
Copy Markdown
Member Author

boegel commented Apr 26, 2016

@wpoely86 please review?

if modtool is None:
elif modcmd == 'lmod':
# check value of $LMOD_CMD as fallback
modcmd = os.environ.get('LMOD_CMD')
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think $LMOD_CMD should get preference for $PATH. The Lmod source script only sets $LMOD_CMD not path.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not how the framework does it (when Lmod is used as value for --modules-tool)...

It's mostly for backwards compatibility: what if you have both lmod in your $PATH, and $LMOD_CMD defined to something else? Weird setup, sure...

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, then $LMOD_CMD wins. It's the way Lmod works. The whole $PATH thing should be a fallback. Unless you do it very explicitly yourself, lmod will not be in the $PATH.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, and since that's how people have been doing it for a while (making sure lmod is available), we need to take backwards compatibility into account...

In practice, it really shouldn't matter: if you don't have lmod in $PATH, it'll pick up $LMOD_CMD. So fine, right?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I would pick first what Lmod will pick: $LMOD_CMD. Whatever you do with your $PATH doesn't really matter.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, ok, but that should be considered in a separate PR.

And this that's a change that breaks backward compatibility, I'd like to talk this over with a couple of the 'regulars' before it gets merged.

So, let's merge this PR, and change it to let $LMOD_CMD win consistently in both the bootstrap script and framework itself in a stand-alone PR.

@boegel
Copy link
Copy Markdown
Member Author

boegel commented Apr 26, 2016

@verdurin Thanks for testing
@wpoely86 Thanks for reviewing

Follow-up on giving $LMOD_CMD preference will be done in a separate PR; up for tackling that @wpoely86?

@boegel boegel merged commit 03d4871 into easybuilders:develop Apr 26, 2016
@boegel boegel deleted the bootstrap_LMOD_CMD branch April 26, 2016 10:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants