Last modified 12 years ago Last modified on 05/14/2008 12:20:45 AM

Russell Owen's Setup Use Cases

See also:


Current Terminology

  • Activate/Setup?: put a package on the path.
  • Declare: memorize the name and version of a package. This comes in various flavors:
    • local/machine-wide: only the user can see it if it's local, else all users on the machine can see it
    • current/not current: the current version is set up if no version is specified
  • Install: copy the header files, libraries, etc. into a standard location. This comes in two flavors:
    • local/machine-wide: only the user can see it if it's local, else all users on the machine can see it

An installed package must also declared (at least if is to be seen and used). But a machine-wide declared packages must also be installed machine-wide; anything else leads to other users seeing that the package exists but not being able to access it. Thus we have these valid states:

  • not declared
  • declare local (not installed)
  • install (and declare) locally
  • install (and declare) not local

I propose eliminating the term "declare" from the interface (it might still be useful for explaining what is going on under the hood) and renaming the actions that lead to these states as follows:

  • install devel (formerly declare local)
  • install local? Not really needed; I suggest we ditch it (and so does KT).
  • install machine-wide

and I use this terminology below.

KT proposes eliminating what I call a local install. My terms map to KT's as follows:

  • machine-wide -> local
  • local -> n/a
  • devel -> devel

Use Cases

These use-cases only deal with svn working copies.

A developer works on one package while using released versions of the other packages

Preferred techniques:

  • Activate the package (e.g. "setup foo" or "setup -r ."). This is simplest.
  • "install devel" the package before activating it. This is one extra step once, but no more work afterwards and scales well to developing with more packages (see next use case).
  • Similarly all the fancier techniques for developing on multiple packages can be used (see next use case).

A developer uses two or more svn working copies simultaneously

The developer may not be modifying all these packages, but somebody is. The point is that the developer needs to frequently modify or update the packages.

Preferred techniques:

  • "install devel" all packages. This is simplest because you can activate the highest level package to activate its dependencies. You don't have to individually activate each dependent package (as you would if you only used "activate -r .") and you don't have to remember to reinstall after every change (as you would if you used "install machine-wide").
  • "install local" some of the packages. This is a bit clumsy because after every change one must remember to reinstall the package. It can be useful if one wants to save a snapshot of a working system, but as KT points out you could just as easily install machine-wide; other users can then see your package, but so what?

  • "install machine-wide" some of the packages. This is good if several folks are developing using the same software stack and they all need the "latest and greatest" from the svn trunk.
  • (Bad) active without installing. This is clumsy because one has to activate each package separately. One can avoid this using some kind of metapackage/snapshot, but then you are simply replacing the existing install database mechanism with a different one -- why bother?


If eups is modified to prefer newer versions then the concept of "current" becomes much less important. It would only be needed to temporarily prefer an older package or to pick between two different working copies. I suspect it would be better to only mark packages "current" when needed, and normally install packages without the designation. But then when one installs a new package the declaration should look for existing "current" packages and ask whether to remove the designation.

Desired Changes

A developer/maintainer should have some way of installing a new system package machine-wide without having to jump through stupid hoops like undeclaring $LSST_DEVEL

A developer should NOT be able to accidentally declare a package machine-wide unless the code is machine-wide accessible. This is discussed at the beginning.