MathGroup Archive 2004

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: sharing packages between multiple installations

Hello, Peter.

Hopefully I can clear up a few things.  First...

$BaseDirectory === $AddOnsDirectory
$UserBaseDirectory === $UserAddOnsDirectory

They are simply new names (new to version 5), but have the exact same 
values.  The old names are deprecated, and thus undocumented (in theory, 
anyway...your email points out an omission which I'll touch on later).  I 
know this seems a bit odd and potentially inconvenient, but I think I can 
say with a fair bit of certainty that it won't happen again.

I say above that the behavior of these symbols is identical, but it's 
possible that the behavior will be different if you assign values to them.  
However, you should *not* assign values to them, so any differences in that 
behavior don't concern me too much.

The way to redefine these symbols is to use an environment variable.  See 
appendix A.7.1 for a discussion of the environment variables 
variables will change the locations for both kernel and FE, which will fix 
some of your problems (you are only resetting the kernel's value using your 
current method).

For your puzzles, now...

1) If you've packaged up everything up as an application, then you should 
put your entire application in its own subdirectory in one of the following 
	$BaseDirectory/Applications (for a machine-wide install)
	$BaseDirectory/Autoload (machine-wide, loads automatically)
	$UserBaseDirectory/Applications (for a user-specific install)
	$UserBaseDirectory/Autoload (user-specific, loads automatically)

In that subdirectory, you should have your files organized as...

	<addon>/*.m (files on the kernel's $Path)
	<addon>/Kernel/init.m (the file which runs if the package is put in 
	<addon>/Documentation/English (documentation files)

If you don't want to package things up as an addon, then the documentation 
could simply be in...

2) I've already explained why $AddOnsDirectory is undocumented.  I'm not 
sure how you're reading the "mixing" of WRI stuff with non-WRI stuff.  It 
is true that official WRI application packs will install stuff in the right 
locations in $UserBaseDirectory or $BaseDirectory...maybe that's what 
you're referring to.  But out-of-the-box, all Mathematica will do is create 
a directory structure (no files) inside of these directories to help you 
figure out the right places to drop things.  But unless you own application 
packs, this isn't an issue.  If you do own application packs, then you 
could make your change to $BaseDirectory, but install the application packs 
in $UserBaseDirectory (I wouldn't recommend moving $UserBaseDirectory to a 
shared network directory...that could cause a number of conflicts between 

3) I've reported the problems with references to 
$AddOnsDirectory/$UserAddOnsDirectory and the wrong appendix reference 
(should be A.8.2) to the appropriate people for fixing in the next release. 
 Thanks for mentioning it.

Let me know if you have any further questions.


John Fultz
jfultz at
User Interface Group
Wolfram Research, Inc.

On Mon, 16 Feb 2004 09:00:02 -0500 (EST), Peter Dickof wrote:
> Configuration: We have multiple Windows machines with separate
> single-machine V5.0.1.0 Mathematica licenses connected to a network.
> Each machine has mathematica installed on its C-drive as usual.
> Intent: We wish to share some packages that we have written by storing
> them on a network drive available to all these machines. That way we
> don't have to copy (and recopy and worry about version changes, etc
> etc) to everyone's local drive.
> Progress:
> I have found the mathematica symbols $AddOnsDirectory and
> $UserAddOnsDirectory (They don't appear in the Help browser index!) by
> looking at the help browser here:
> "Add-Ons&Links->Standard Packages->Appendix: How
> Mathematica)->AutoLoading Packages" and then finding the section
> "autoload directory". All I need to do is define (after unprotecting)
> the $AddOnsDirectory to point to the right place (L:/mystuff), and
> everything seems to work just the way I want. All the WRI stuff seems
> to work in its original location on the C: drive, and so does ours in
> its location on L:. I plan to put this in the initialization for every
> workstation.
> Puzzles:
> 1) How do we make the help notebooks we have written for our packages
> available in the help browser in a similar way? I set up
> BrowserCategories, etc etc which worked on the C drive in the
> appropriate location under Version 4.0, the question relates only to
> keeping them on the network drive and separate from the WRI
> distribution. The documentation says "You should place all new
> material that you want to add to the Help Browser in the
> Documentation/English/AddOns directory, which is specifically intended
> for the purpose.", but I want our help kept in a central location just
> like our code is (and preferable in the same directory with the code
> rather than split up the way WRI does it). Where/what symbol can I use
> to add our stuff to the search path used by "rebuild help index"?
> 2) Why is the ($AddOnsDirectory) so well hidden in the documentation?
> Is this not intended to be used in this way? There is also a
> $BaseDirectory and $UserBaseDirectory (see Appendix A.8.2, help
> browser "Mathematica Book->Mathematica reference guide->Mathematica
> File Organization->Loadable Files"), but that seems to require placing
> WRI stuff on the network drive too, which seems a) unnecessary b)  a
> possible violation of our license and c) to mix up the WRI stuff and
> our own stuff. I would prefer to keep our work completely separate
> from the baseline installation.
> 3) The help file section "AutoLoading Packages" identified under
> "progress" has a hyperlink to Appendix A.8.7 but the link does
> nothing! Is there an Appendix A.8.7? How do I find it?
> Thanks in advance!
> Peter Dickof

  • Prev by Date: Re: sharing packages between multiple installations
  • Next by Date: Re: Shared Functions
  • Previous by thread: Re: sharing packages between multiple installations
  • Next by thread: Re: sharing packages between multiple installations