What's the recommended way to use packages from spack

[Ondřej Čertík]

Hi Todd,

As you know, I've been evaluating the differences between Spack and
Hashdist. So I have quite a few questions. I'll just start with one
here.

What is the recommended way to use spack for work? I followed the
documentation and did:

certik@redhawk:~$ spack install python
==> python is already installed in
/home/certik/repos/spack/opt/unknown_arch/g...@4.9.2/pyt...@2.7.8-3cadb17a.
certik@redhawk:~$ spack load python
==> This command requires spack's shell integration.

To initialize spack's shell commands, you must run one of
the commands below. Choose the right command for your shell.

For bash and zsh:
. /home/certik/repos/spack/share/spack/setup-env.sh

For csh and tcsh:
setenv SPACK_ROOT /home/certik/repos/spack
source /home/certik/repos/spack/share/spack/setup-env.csh

certik@redhawk:~$ . /home/certik/repos/spack/share/spack/setup-env.sh
certik@redhawk:~$ spack load python
bash: module: command not found


Does it meant that to use spack, I have to have the modules installed?
I can do that, but I wanted to make sure first, that the recommended
way to use spack is through modules.

Ondrej

[Todd Gamblin]

Hi Ondrej,

So, the assumption so far is that either modules or dotkit is installed (dotkit is an LLNL thing that is pretty much like modules).  What should really happen, if one does not have modules, is that Spack should install it for you and that should be worked into the shell support, but that's not how it works now.

If you have sourced share/spack/setup-env.sh, then MODULEPATH and DK_NODE are set up for you so that Spack's modules are known to whichever module system you're using.  So you can do two things:

1) You can just run "module avail" or "use -l" and you'll see the spack modules in the list of available packages.  Example from LLNL:

(cab668):~$ module avail

----------------- /g/g21/gamblin2/src/spack/share/spack/modules/chaos_5_x86_64_ib -----------------

Image...@6.8.9-10%g...@4.4.7-4df950dd lib...@1.11%g...@4.4.7-86650d54

SAM...@3.9.1%g...@4.4.7-57c9a0ca         lib...@2.9.2%g...@4.4.7

adept-utils@1.0%g...@4.4.7-5adef8da      lib...@2.9.2%g...@4.4.7-a8337315

adept...@1.0.1%g...@4.8.2-774647b6    llvm@3.0%g...@4.4.7

adept...@1.0.1%g...@4.8.2-c8f018d1    memaxes@0.5%g...@4.4.7-19ba57cb

adept...@1.0.1%in...@15.0.0-28963715 me...@8.0.5%g...@4.4.7-22dd4c4b

adept...@1.0.1%in...@15.0.1-ae1dfc92 me...@5.1.0%g...@4.4.7

...

(cab668):~$ module load qhull@1.0%g...@4.4.7

The disadvantage to doing things this way is that the names are kind of long and complicated.  The advantage is that this interface is familiar to users, who generally already know how to use modules.

2) You can use "spack use" and "spack load".  This is what I do, because I have no desire to remember the names above.  

The difference is that "spack use" takes a spec, so you can use the same syntax you used to install the package.  All you'd ave to type is:

(cab668):~$ spack load qhull

That will resolve the 'qhull' spec to the name of its module and it'll load the module for you.  If it's ambiguous, it'll warn you.  E.g.:

(cab668):spack$ spack find hwloc

==> 3 installed packages.

-- chaos_5_x86_64_ib / g...@4.4.7 --------------------------------

hwloc@1.9

-- chaos_5_x86_64_ib / in...@14.0.2 -----------------------------

hwloc@1.9

-- chaos_5_x86_64_ib / in...@15.0.1 -----------------------------

hwloc@1.9

(cab668):spack$ spack load hwloc

==> Error: Multiple matches for spec hwloc.  Choose one:

hwloc@1.9%g...@4.4.7=chaos_5_x86_64_ib

hwloc@1.9%in...@15.0.1=chaos_5_x86_64_ib

hwloc@1.9%in...@14.0.2=chaos_5_x86_64_ib

(cab668):spack$ spack load hwloc%gcc

Above, hwloc%gcc is unambiguous, so you can refer to the gcc build that way.

This is good for interactive use, because it's easy to load what you want.  If I were putting this in a script I might use "module load <full name>"  because it won't be ambiguous.

-Todd

On 4/22/15, 9:41 AM, "Ondřej Čertík" <ondrej...@gmail.com> wrote:

Hi Todd,

As you know, I've been evaluating the differences between Spack and

Hashdist. So I have quite a few questions. I'll just start with one

here.

What is the recommended way to use spack for work? I followed the

documentation and did:

certik@redhawk:~$ spack install python

==> python is already installed in

/home/certik/repos/spack/opt/unknown_arch/g...@4.9.2/python@2.7.8-3cadb17a.

certik@redhawk:~$ spack load python

==> This command requires spack's shell integration.

  To initialize spack's shell commands, you must run one of

  the commands below.  Choose the right command for your shell.

  For bash and zsh:

      . /home/certik/repos/spack/share/spack/setup-env.sh

  For csh and tcsh:

      setenv SPACK_ROOT /home/certik/repos/spack

      source /home/certik/repos/spack/share/spack/setup-env.csh

certik@redhawk:~$ . /home/certik/repos/spack/share/spack/setup-env.sh

certik@redhawk:~$ spack load python

bash: module: command not found

Does it meant that to use spack, I have to have the modules installed?

I can do that, but I wanted to make sure first, that the recommended

way to use spack is through modules.

Ondrej

--

You received this message because you are subscribed to the Google Groups "Spack" group.

To unsubscribe from this group and stop receiving emails from it, send an email to spack+un...@googlegroups.com.

To post to this group, send email to sp...@googlegroups.com.

Visit this group at http://groups.google.com/group/spack.

For more options, visit https://groups.google.com/d/optout.

[Ondřej Čertík]

Hi Todd,

Thanks for the reply. I will install modules and try again.

How do I load multiple packages into same environment? Here is an
example of a profile that I need for my work:

https://gist.github.com/certik/dc742a3e5fa772aa88cd

It has about 80 or so packages, most of them independent, and I need
to load all of them.

Ondrej

[Todd Gamblin]

On 4/22/15, 2:01 PM, "Ondřej Čertík" <ondrej...@gmail.com> wrote:

>
>Thanks for the reply. I will install modules and try again.
>
>How do I load multiple packages into same environment? Here is an
>example of a profile that I need for my work:
>
>https://gist.github.com/certik/dc742a3e5fa772aa88cd
>
>It has about 80 or so packages, most of them independent, and I need
>to load all of them.

Currently you'd have to load the installed modules for each of those --
there's no way to save an environment with lots of packages in it. I
think having something like a profile would be a really nice feature, but
it's not there at the moment. The focus thus far has been mainly on
building and installing -- the users at LLNL pretty manage their
environments either by knowing where things live or by using
dotkits/modules. There isn't really a "grouping" like you want, but it's
been discussed.

-Todd

[Malcolm Cook]

Ondřej,

If you are using the modules (as opposed to dotkit) system, then you can use it to create modules whose only purpose is to load a set of other modules, using the `module` command.  See http://modules.sourceforge.net/man/modulefile.html for what sounds like a treatment of you use case.

~Malcolm

module [ sub-command ] [ sub-command-args ]

Contains the same sub-commands as described in the module(1) man page in the Module Sub-Commands section. This command permits amodulefile to load or remove other modulefiles. No checks are made to ensure that the modulefile does not try to load itself. Often it is useful to have a single modulefile that performs a number of module load commands. For example, if every user on the system requires a basic set of applications loaded, then a core modulefile would contain the necessary module load commands.

[Todd Gamblin]

Another interesting feature, though maybe not exactly what you want, is Lmod's ability to save a particular module environment. You can get your favorite packages in a profile, save it, and recall it later using built-in Lmod features:

In general I think Lmod is a pretty nice solution and might be something to consider for future lab machines. I'd probably focus on having spack generate Lmod if I were to pick a module system.  Lmod has some support for hierarchical module namespaces, e.g.:

$compiler/$compiler-version/$mpi/$mpi-version/$package-$version

I think it would be fairly simple to code something up that, given a set of dimensions, would fill out the above configuration space and generate Lmod files for it. You could also have spack generate more complicated hierarchies with more layers if other things, like say CUDA version, started being a major decision for users.

-Todd