In your situation, the standard approach is usually different. This means, I use something like this only
when I need the functionality of the Visualization and Utilities inside my package, not to re-export them.
What about creating an directory structure the following way
│ └── init.m
And in the
Get your sub-packages. Placing this in folder which Mathematica can find lets you
<<PQR` and everything should work as expected.
If you want to have an example where such approach is used, then look at
$InstallationDirectory/AddOns/Packages/BarCharts. You load
<<BarCharts`, but there is no package
BarCharts.m, it's only a collection of different sub-packages which are loaded through the
│ └── init.m
There was a follow-up question from Verbeia in the comments:
This works great, thanks! But one quick question - is there a reason why it works for Get and gives an error Needs::nocont: Context PQR` was not created when Needs was evaluated. >> when using Needs
Yes, the reason is that
Needs["PQR`"] expects that a context
PQR` is actually created which is not the case if it is really just a dummy directory/package.
- when you set up the structure like I described
- and there is no
.m file which is named after the parent package directory
- and every sub-package only creates its own context by calling
then you get this warning when you call
If you inspect now the BarCharts example in more detail, you see that they, although using different file names, always use
BeginPackage["BarCharts`"] and therefore introduce there different functions in the same namespace/context. The question is here, what you want to achieve with your package structure, because after loading your package all exported functions are visible without you noticing they are in different sub-packages/contexts.
What I usually do is the following: When my packages contain several sub-packages, then there is still one main-package which provides core functionality. To give an specific example: An image processing package
IP could provide basic functions under
IP/IP.m while addressing more special things in sub-packages like
IP/Segmentation.m. The simplest solution for you is therefore to make a package file
PQR/PQR.m which introduces the namespace/context
PQR` and the message will be gone.
Note that if some subpackages use functions that are defined in other subpackages, you will need to order the calls to