Could you be more specific as to the "environment-modules" packages?

Do these produce a stand-alone executable, or do these require to be 
installed on both the development and target environments (machines)?

Part of the issue is having the environment for a build requiring 
versions or entire packages that are not available in the "stock" 
distribution, but part is having the environment available at run-time 
for the built program.

Does this also work for buildable environments that require libraries 
incompatible with the "stock" distribution, particularly after the build 
during run-time?

Yasha Karant

On 10/16/2013 01:28 PM, Jeffrey Anderson wrote:
> It seems to me that the "environment-modules" package available from
> EPEL can address many of your needs.
>
> We use it to provide access to multiple versions of python, gcc, boost,
> gsl and many other tools and libraries, all without interfering with
> necessary system-level operations.  It is quite flexible, has a
> relatively low learning curve, and is widely used.  It allows users to
> easily switch back and forth between different versions of these tools.
>
> Need python 2.7.2?
> 'module load python/2.7.2'
>
> Want to switch to 2.6.4?
> 'module switch python/2.6.4'
>
> Want to go back to the default system python?
> 'module unload python'
>
> and so on.
>
> Jeff
>
>
> On Wed, Oct 16, 2013 at 1:11 PM, Yasha Karant <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
>     On 10/16/2013 09:12 AM, Jim Fait wrote:
>
>         I run into this all the time, as we have a large number of
>         somewhat incompatible software packages that we are required to
>         have.  What we have ended up doing is placing the real
>         executable somewhere outside the normal path, and then putting a
>         script with same name in /usr/local/bin or /opt/local/bin that
>         encapsulates all of the foreign dependencies and environment.
>           That way, the particular package can live with its
>         requirements alongside the production system, with very few
>         problems seen by the end user.
>
>         Of course, this means writing a number of scripts, in our case a
>         couple hundred, that stay fairly static with changes in the OS
>         or the package in question, and that hide all of the nastiness
>         that otherwise would happen, like a PATH environment variable 10
>         line long.
>
>         Hope this idea helps.
>
>         Jim
>
>
>     Your example is one of the accepted methods for enabling the idea of
>     polymorphism and encapsulation within an otherwise procedural
>     imperative, possibly structured, environment.  Assuming that what
>     you are describing is for both the build environment and the
>     execution environment of the environment/application being built, it
>     should (in most cases) work.  And -- it should be the norm when
>     providing application building environments that do NOT require a
>     virtual machine (e.g., maintaining a "more modern" Linux under
>     VirtualBox under SL6x).
>
>     I do not know which applications/environments you support in this
>     way.  A list of all that are not subject to for-fee or equivalent
>     non-distributable licenses and for which you are willing to provide
>     the scripts greatly would be appreciated.  Maintaining such
>     environments across new major OS environment releases often entails
>     a large amount of effort.
>
>     Yasha
>
>
>
>
> --
> --------------------------------------------------------------
> Jeffrey Anderson                        | [log in to unmask]
> <mailto:[log in to unmask]>
> Lawrence Berkeley National Laboratory   |
> Office: 50A-5104E                       | Mailstop 50A-5101
> Phone: 510 486-4208                     | Fax: 510 486-4204