MathGroup Archive 2004

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

Search the Archive

Re: sharing packages between multiple installations

Thanks, this is much clearer. Following up, I see that in the file
C:\Program Files\Wolfram

there is a line

HelpDirectoryListing[AddOnHelpPath, {FrontEnd`FileName[{$TopDirectory,
"AddOns", "Applications", "AuthorTools"}], 
        FrontEnd`FileName[{$TopDirectory, "AddOns", "Applications",

which is responsible for the appearance of any packages I am sharing.
I do not understand how this line works.  

The documentation for HelpDirectoryListing says that the arguments are
supposed to be a directory and two (optional) arguments with
True/False values.

argument 1
I now understand that AddOnHelpPath is a directory which is probably
being set by MATHEMATICA_BASE, etc. Note that this is not explained in

1a) That documentation seems to confuse AddOnHelpPath and
1b) That documentation says "The directories are specified using the
FrontEnd`FileName function. ". I can find no documentation for either
System`FileName or FrontEnd`FileName, and using ?? only tells me that
they have the attributes {HoldAll,ReadProtected}.
1c) I can replace this line with
HelpDirectoryListing[absolutePathString,optional args] 
and get results that make sense, but when I try
I get no joy. Why doesn't this work?

argument 2
This is supposed to be True/False, but it contains
{FrontEnd`FileName[{$TopDirectory, "AddOns", "Applications",
        FrontEnd`FileName[{$TopDirectory, "AddOns", "Applications",
2a) How does a list evaluate to True or False?
2b)$TopDirectory does not appear in the MasterIndex. How is it related
to all of this?
2c) What does each of those FrontEnd`FileName functions do?

argument 3 is unused, this means that /Documentation/English
subdirectories are to be used.

One more reality check. I have this idea that I would like our
packages to be self contained and in one place, ie, I would like to
have a single directory contain the packageName.nb, packageName.m,
packageDocumentation.nb, init.m, BrowserCategories.m, etc etc. It
seems to me that this would be easier for maintenance than having
stuff distributed in /Documentation/English, etc. (I keep forgetting
to move stuff, then can't figure out why it hasn't changed, etc etc).

A HelpDirectoryListing[packageDirectoryRoot,True,False] seems tailor
made for this. Each of my package directories can then be inserted,
removed, etc completely independent of any other (assuming that the
needs identified in BeginPackage  statements are respected.), and no
hand editing of the BrowserCategories.m file in the directory
containing all the packages is required.

Similarly, I could use this to create a BrowserCategories.m file in
the package directory treating it as the root for subpackage
subdirectories each containing the subpackageName.nb,
subpackageName.m, subpackageDocumentation.nb, init.m,
BrowserCategories.m, etc etc. If none of these files appeared in the
package directory itself, I could handle the subpackages independently
without having to edit the BrowserCategories.m file in the package

Are there any negative implications to this (beyond the obvious
unilingual restriction)?

Now having done all of this, I have a directory tree with multiple
packages and subpackages which Mathematica_Base points to. I wish to
create a second (initially identical) such tree for development and
switch between them simply by changing the environmental variable and
rebuilding the help index. When a new version is to be released from
development to production,  I want to delete the old production tree,
copy the development tree over. Then all production users are updated
(though the documentation is only updated when they rebuild their help

A similar scheme has been useful with different programming
environment in the past. Is this scheme possible/practical in the way
outlined above? Am I missing something more natural to the Mathematica

Peter Dickof

On Tue, 17 Feb 2004 05:26:34 +0000 (UTC), John Fultz
<jfultz at> wrote:

>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...
>	$BaseDirectory/Documentation/English
>	$UserBaseDirectory/Documentation/English
>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: Re: Help Browser issue in 5.0.1 on Mac OS X
  • Next by Date: Re: how to explain this weird effect? Integrate
  • Previous by thread: Re: sharing packages between multiple installations
  • Next by thread: Shared Functions