Of course there is a bit of an ambiguity as to which David you are responding to ;-) !

But the approach of using the 2-argument form of BeginPackage is tried and true -- it has worked for us for about 25 years since version 1 of Mathematica. And, indeed, it just worked for me now.

I am attaching two packages, TestPackage1 and TestPackage2. They each have one function, TestPackage1 and TestPackage2 respectively. The function TestPackage1 depends on TestPackage2.

If both are placed in a directory called dir and one then appends dir to $Path using

$Path=AppendTo[$Path,dir] 

or, more simply, if you simply put both packages in this directory

FileNameJoin[{$UserAddOnsDirectory, "Applications"}]

which you can open using

SystemOpen[FileNameJoin[{$UserAddOnsDirectory, "Applications"}]]

Then execute

Needs["TestPackage1`"]

and all works fine. One gets

In[4]:= TestPackage1[x]

Out[4]= Sin[x]

and life (an Mathematica) is problem-free from then on (at least in this small universe.

Attachments:

The general approach to having one package make use of another package is to start your first package's Begin function in the following way (using your example):

BeginPackage["RKG`", {DoublePendulum`"}];     

Then you only execute a Needs on the "RKG`" package context.

see the documentation for BeginPackage for a discussion:

http://reference.wolfram.com/language/ref/BeginPackage.html

Of course then the second package cannot depend on the first one's functions--package dependency can only can go one way down a tree.

Mikel, If you will read my tutorial you will see how to name your packages and have access to them. I don't feel like reproducing all of it right here. But also you will have to include the second argument in the BeginPackage statement that declares subsidiary packages that are needed in a tree structure - as David Reiss advises.

There is a way to divide an application into subpackages that all have the same Context and that call routines from each other, criss-cross. You don't have to use a tree structure. Essentially you break each subpackage into two files - a Public file that declares the exported names and a dummy Private section, and a second Private file with no public exported names. Then in the init.m file that launches the application all the Public files are read first and then afterwards all the Private files are read. Various other initiations can also be done in the init.m file. The Private routines then know all the names and can use them in the private code. I've used this in the GrassmannCalculus application without any problem.

I have one doubt about packages. I have implement two packages where package1 call a function which is defined in package2. Is correct the next implementation?

BeginPackage[["Package1"] myfunction::usage=""; Begin["Private"]; myfunction[x_]:= Module[{temp}, temp=fun1(x) End[]; EndPackage[]; ********************************************************* BeginPackage[["Package2"] fun1::usage=""; Begin["Private"]; fun1 Module[{temp}, temp=2*x: End[]; EndPackage[];

Thank you for this nice tutorial. I would only add that when programming packages in notebooks, you don't get the nice reload button, but you can reload the package using the "Evaluation->Evaluate Initialization Cells" menu command.

One option: you can always create a self-answered question on Mathematica.SE and publish there a description of the package and the link to your GitHub code repository.

• Setting Up Mathematica Packages
• Creating Mathematica packages
• Custom package development: Basic steps
• How to make a package in Mathematica