sharing packages between multiple installations
Peter Dickof
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
Bobby R. Treat
$AddOnsDirectory
$BaseDirectory
$UserBaseDirectory
you can place "application" directories, such as "Ersek", where I put
all the packages I've downloaded that Ted Ersek wrote,
"TensorCalculus" where I put David Park's package for tensor calculus,
and "DrBob" where I put things I've done. In "DrBob" I have "Master.m"
from which I load utilities I've written.
There's a palette in the directory
C:\Documents and Settings\All Users\Application
Data\Mathematica\Applications\DrBob\FrontEnd\Palettes
and Help Files (BrowserCategories, etc.) in
C:\Documents and Settings\All Users\Application
Data\Mathematica\Applications\DrBob\Documentation\English
So... I think you're not far from what you want.
Bobby
pdi...@sasktel.net (Peter Dickof) wrote in message news:<c0qjkn$kb2$1...@smc.vnet.net>...
John Fultz
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
MATHEMATICA_BASE and MATHEMATICA_USERBASE. Using these environment
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
places...
$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
Autoload)
<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
users).
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.
Sincerely,
John Fultz
jfu...@wolfram.com
User Interface Group
Wolfram Research, Inc.
Peter Dickof
C:\Program Files\Wolfram
Research\Mathematica\5.0\Documentation\English\AddOns\BrowserCategories.m
there is a line
HelpDirectoryListing[AddOnHelpPath, {FrontEnd`FileName[{$TopDirectory,
"AddOns", "Applications", "AuthorTools"}],
FrontEnd`FileName[{$TopDirectory, "AddOns", "Applications",
"XMLCapabilities"}]}]
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
FrontEnd->FrontEndOptions->GlobalOptions->FileLocations->AddOnHelpPath,
1a) That documentation seems to confuse AddOnHelpPath and
PreferencesPath.
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
HelpDirectoryListing[$BaseDirectory<>"RestOfAbsolutePathString",optional
args]
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",
"AuthorTools"}],
FrontEnd`FileName[{$TopDirectory, "AddOns", "Applications",
"XMLCapabilities"}]}
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
directory.
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
indices).
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
environment?
Peter Dickof