Hi all, This might be a bit off topic, but I have at least a partial solution to this type of versioning in Spack, a package manager I'm working on (which is not yet nearly as mature as EasyBuild).
Spack actually has recursive versions as Markus suggests. The version of any
package installed is:
- package name
- package version
- compiler + compiler version
- any build variants (e.g. +debug, -qt, etc)
- platform
And recursively, all that for each dependency. Basically the version is a DAG
with annotations for each package in it. I call the DAG a "spec". There is
more on that here:
http://scalability-llnl.github.io/spack/packaging_guide.html#abstract-concrete-specs
Unlike EasyBuild, there isn't a toolchain that includes MPI, FFT, etc. -- those
are all just dependencies and are included in the dependency versions above, so
it's a little more versatile because the version model allows you to compose
things without writing a new, specially named python file (e.g., "goolf").
There IS a compiler version in Spack, and each "compiler" really includes cc,
cxx, fc, and f77 much like the compiler in the EB toolchain does. If the fc
and cc versions differ (which is only for some compilers like XL) I just take
the cc version. This is jacky but at least the recursive part is taken care of
and I don't have to lump all that into one opaque version.
Users don't have to care about a special compound toolchain name -- they can
use a partial spec to query what they want based on specific parts. e.g., you
could say:
spack find %[email protected] ^[email protected]
And this will find all the packages installed that use that mvapich/gcc
combination.
The recursive versions aren't completely cumbersome in the UI because I only
display a hash unless the user really cares.
e.g., if I want to see what versions of STAT (our debugging tool) are
installed, I say:
(cab670):~$ spack find stat
== chaos_5_x86_64_ib ===========================================
-- [email protected] ---------------------------------------------------
stat @2.0.0-6f7378e3
chaos is the platform and gcc is the compiler -- they're part of the version
but here they're just grouped into subsections. The hash there is a hash of
the recursive version. Hashing is deterministic, so if something has the dame
deps as something else, you can at least see that at a glance b/c it will have
the same hash.
If I really care what the deps are, I can expand the hash out to a DAG:
> (cab670):~$ spack find -l stat
> == chaos_5_x86_64_ib ===========================================
> -- [email protected] ---------------------------------------------------
> [email protected]
> ^[email protected]
> ^[email protected]
> ^libdwarf@20130729
> ^[email protected]
> ^[email protected]
> ^[email protected]
> ^[email protected]
The DAG there doesn't show all connections, just all unique nodes with some
nesting.
And as I said above -- you can query to find things with specific dependencies,
e.g. if you wanted to find something that depends on a particular fftw version,
you would write:
$ spack find ^[email protected]
Maybe something like this could go into EB? Or maybe there's some potential
for a composite versioning scheme in the toolchain files?
I am not sure that you could encode all this in lmod names.
-Todd
On Jun 13, 2014, at 1:06 PM, Markus Geimer <[email protected]>
wrote:
> Hi,
>
>> i don't count myself as average user, but even i don't know what ictce
>> 5.5.0 means. luckily, module show tells me
>
> But it may require recursion. For example, goolf loads gompi,
> which then loads GCC and OpenMPI.
>
>> maybe we need a tool/option similar to module av that shows the module
>> names and one line description?
>
> Could this be encoded in the 'module help' output, before or
> after the generic help text?
>
> I guess 'module help' is more widespread among users than
> 'module show'...
>
> Markus
>
> --
> Dr. Markus Geimer
> Juelich Supercomputing Centre
> Institute for Advanced Simulation
> Forschungszentrum Juelich GmbH
> 52425 Juelich, Germany
>
> Phone: +49-2461-61-1773
> Fax: +49-2461-61-6656
> E-mail: [email protected]
> WWW: http://www.fz-juelich.de/jsc/
>
>
>
> ------------------------------------------------------------------------------------------------
> ------------------------------------------------------------------------------------------------
> Forschungszentrum Juelich GmbH
> 52425 Juelich
> Sitz der Gesellschaft: Juelich
> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
> Prof. Dr. Sebastian M. Schmidt
> ------------------------------------------------------------------------------------------------
> ------------------------------------------------------------------------------------------------
>
smime.p7s
Description: S/MIME cryptographic signature
