|
From: R.K. O. Ph.D. <rk...@Ow...> - 2002-07-29 18:56:20
|
Hello, I have a couple of questions, because of all the respondents you may be the most affected by the semantic changes. So for the example below you have the bar module load foo with: module load foo/bar and that the .modulerc file exists at the modulefile "root"? If so, then the proposed new semantics would be that the .modulerc file exists in the ./foo directory and would likely be: #%Module1.0 module-version 4.1.1 obsolete_deleted_May2000 module-version 5.2 bar # this is the version to be used with package bar module-version /5.2.1 OBSOLETE-1020718c module-version /6.2 default where only "versions" are given with an optional prepended '/' and you continue to use "module load foo/bar" to load foo/5.2 . This .modulerc set-up would backwardly compatible too. R.K. On Sun, 28 Jul 2002 mi...@im... wrote: > "R.K. Owen Ph.D." <rk...@Ow...> writes: > > > 1) Does anyone use the .modulerc files? To do things like > > module-version > > module-alias > > We use .modulerc files extensively. We use Modules for about 60 > packages and have about 200 module files for various versions of > these. We have a .modulerc for most of these packages with one or > more module-version lines. Example: > > #%Module1.0 > > module-version foo/4.1.1 obsolete_deleted_May2000 > module-version foo/5.2 bar # this is the version to be used with package bar > module-version foo/5.2.1 OBSOLETE-1020718c > module-version foo/6.2 default > > We don't use module-alias. > > > 2) Caching for "module avail". I rarely enable it for my own > > systems, but I have maybe 50+ modulefiles on each. > > We have this enabled but could live without it. > > We are still using a locally hacked version of the old 3.0beta release > but we are hoping to upgrade to a recent rko version at some point. > |
