This question follows on from my earlier question Can Wolfram's Player Pro Use Proprietary Packages.

That question appeared to have established that, yes, PlayerPro can use proprietary packages.

Hmmm....? I've got two problems (to start) one of which I'll describe here and the second in a separate question.

I purchased a PlayerPro license ($200 USD) for OS X to evaluate what it really can and does do. I installed it on a machine that had no other Mathematica installation. I tested its installation and functionality by running a couple of simple completely self-contained CDFs on it without any trouble.

I then transferred copies of three files to the PlayerPro equipped machine and located them in the following directories:

/Users/username/Library/MathematicaPlayerPro/Applications.myPackage.m /Users/username/Library/MathematicaPlayerPro/Applications.myNotebook.nb /Users/username/Library/MathematicaPlayerPro/Kernel.init.m

myPackage.m holds proprietary functions.

myNotebook.nb provides a Grid of InputFields and a Button to execute code contained in myPackage.m. All of its code resides in an initialization cell (but that starts to get into my next question).

init.m contains the following code:

(** User Mathematica initialization file **)

The comparable deployment on my machine running Mathematica works perfectly.

On the PlayerPro machine, not so much.

I have shut down and restarted PlayerPro and the problem persists. I have rebooted the machine, launched PlayerPro and the problem persists.

Upon opening myNotebook.nb, I can see plainly that none of the function names from myPackage.m have run. They all remain blue. The package has not loaded automatically. As the notebook depends almost entirely on the code in the package nothing in it executes.

Neither does it appear that the initialization cell runs.

I then went into:

PlayerPro >>> Preferences >>> System >>> Edit Trusted Directories

and specifically added the:



directories, restarted, rebooted, still nothing.

Does anyone have any ideas of how to get this working?

I've actually phoned Premier Support about this. The did not have a ready answer. If I hear anything useful from them I'll post it.

Update 1: I have used Encode to encode the package in question.

I have made the assumption that the init.m package would not require encoding. Perhaps that assumption needs reexamination.

Update 2: Encoding init.m has no affect.

Update 3: I created a notebook to test the following two lines of code for loading the package:




Get::noopen : Cannot open Users/username/Library/MathematicaPlayerPro/Applications/myPackage`

I have also tried:

Needs::nocont : Context myPackage` was not created when Needs was evaluated.



Get::noopen : Cannot open Users/username/Library/MathematicaPlayerPro/Applications/myPackage`
Needs::nocont : Context myPackage` was not created when Needs was evaluated.      

Update 4: Premier Support suggested some of the same things that Albert does in his answer below (still working through all of Albert's suggestions). They did discover something peculiar with PlayerPro:

I know that the main difference between this procedure and what you may have been doing with your package is that you have your Needs/Get statement inside of the PlayerPro init.m file. I did try doing the same, and found that it did not load the package. I will check on this issue with our developers to get more information.

Update 5: Sorry for all these updates, but this now appears like a bug in (at least) PlayerPro The init.m file whether encoded or not simply doesn't do its job, at least not in anyway similar to how it works in full blown Mathematica.

I have successfully found a workaround (but not a happy one), with the generous assistance of both answers made to this question. Still, having Wolfram provide either a fix or at least a readily available explanation of why it differs in PlayerPro from Mathematica would save a lot time and frustration.

  • $\begingroup$ have you used Encode to encode your package files? PlayerPro can only load encoded package files... $\endgroup$ Commented Mar 28, 2013 at 0:08
  • $\begingroup$ @AlbertRetey -- I was just planning to update my question to state that yes, all along I have used Encode on the package in question. $\endgroup$
    – Jagra
    Commented Mar 28, 2013 at 0:17
  • $\begingroup$ you'll definitely need to also encode init.m, actually you need to encode every file ending in .m if it needs to be read by PlayerPro... $\endgroup$ Commented Mar 28, 2013 at 0:22
  • $\begingroup$ I just have seen that you're not using init.m in the Kernel subdirectory of the package directory but in the "global" Kernel directory. I don't know whether that does work with PlayerPro. Have you tried to Get["myPackage"] directly in the notebook file? To test these things I'd recommend to first start with a very simple notebook that loads the package and e.g. shows a usage message of one of the package functions or make a simple call to one of those. Remember that you can (unlike in CDF-Player) do shift-return evaluations in PlayerPro... $\endgroup$ Commented Mar 28, 2013 at 0:27
  • $\begingroup$ @AlbertRetey -- Will do, then I'll report back. Thx $\endgroup$
    – Jagra
    Commented Mar 28, 2013 at 0:41

2 Answers 2


The general requirements for a package file to be loaded in PlayerPro are listed in this answer which I think you already know about.

My suspection is that your problems are in some detail in your package that might or might not have to do with the fact you are running this in PlayerPro. As usual you should start with something very simple and then add things step by step until your real problem works or you can exactly tell which step led to a problem, otherwise there is just too many small details that can go wrong. I see some potential problems with your calls to Get and Needs, especially you can't mix full path names and context names as in


But the return value of


and the message of


indicate that you rather have a problem in the content of your package file, maybe some piece of code that doesn't work on PlayerPro as expected.

Here is my suggestion for finding out what actually goes wrong:

Load Trivial Example: Get with Full Path

start with something very simple. Create a text file with this content:

testfun::usage="testfun does nothing";

naming it, e.g. "C:\\Users\\albert.retey\\Desktop\\test.txt" (of course adopt the path name to something valid on your computer). Then evaluate the following in Mathematica:


This should create an encoded package, check that it exists and contains something like:

j<hTJue'P+lKh]7t>X#r/N5>m^c0Q )K,<@X>.5bPbTY_m,n@1#W5cPbTYS)Q6i.XXJ.p1

Now create a new notebook with the following content:



Evaluating this should show the usage message of testfun as defined in the package. Once that works in Mathematica, open the same notebook with PlayerPro and see whether that works there, too. If you are running PlayerPro on another machine than Mathematica, then don't forget to change the path to the correct value on the target machine before saving the the notebook.

Load Trivial Example: Needs with adjusted $Path

For Needs to work, the package file must create the correct Context, that means the name of the package file and the context given in BeginPackage need to agree, otherwise you'll get the Needs::nocont message. Here is how you can test whether that works for your encoded package file: Create a notebook with this content and save it in the same directory as your encoded package file:

AppendTo[$Path, NotebookDirectory[]];

Evaluating this should now work both in Mathematica and PlayerPro.

Load Trivial Package from $UserAddOnsDirectory

For the final deployment, you usually want to put the package file in one of those directories that Mathematica or PlayerPro search for packages instead of tweaking $Path. Basically you can copy your file to any directory listed in $Path, but by convention you should either use the Applications subdirectory of either $UserAddOnsDirectory (for installation for single user) or $AddOnsDirectory (for system wide installation).

To do so, copy the encoded package file into the "Applications" subdirectory of e.g.$UserAddOnsDirectory directory. Doing so, we can load it without giving the full path name of the package file and just use the context name of the package in either Get or Needs. Make sure you use the exact outcome of what $UserAddOnsDirectory gives you evaluated in PlayerPro on the target machine. For me $UserAddOnsDirectory is: "C:\\Users\\albert.retey\\AppData\\Roaming\\MathematicaPlayerPro" and the path to the package file then needs to be: "C:\\Users\\albert.retey\\AppData\\Roaming\\MathematicaPlayerPro\\Applications\\test.m". To test this, create another notebook with the following content:


And evaluate it in PlayerPro. Again, you should now see the given usage message. If this doesn't work, make sure the file can be found, e.g. with:

FileNames["test.m", $Path]

Again, you need to create a notebook with this content in Mathematica, open that with PlayerPro and evaluate it in PlayerPro. This will also show whether there are more than the expected instances of the test.m file in your $Path, loading a different package than what you think is also a very common source of errors.

Add actual Content of your Package File

If you have the above running, start with a new file with the name of your own package. Start again with just the trivial content but the correct filename and context. Once that works, add the content. If the loading then doesn't work, restart with an empty package file and add the definitions for your function one by one and check whether each works. That way you should find the insulting code. If you don't see why that piece of code doesn't work in PlayerPro, come back and add that to your question or create a new one...

Final note: I tested this with PlayerPro 8.0.4, I can hardly imagine that these things have changed for version 9 of PlayerPro that came out a few days ago, but if the above doesn't work and you are actually using version 9 of PlayerPro, you might want to add that information.

  • $\begingroup$ As I mentioned in a comment to another answer, after going through all of your suggestions, the init.m file whether encoded or not simply doesn't do its job. Note: I use PlayerPro I'll amend my original question to warn others. Does such an init.m package work for you in an earlier version? One can work around this certainly, but I'd like to understand why it doesn't work. Waiting to hear from Wolfram ;-( $\endgroup$
    – Jagra
    Commented Mar 28, 2013 at 15:35
  • $\begingroup$ @Jagra: From your comment to the other answer I understand that you have now everything running except for the "auto-load" via the "global" Kernel/init.m. Is that correct? I played a little with init.m and also the Autoload directory and it looks like both don't work with PlayerPro. I'll add that to my answer to your other question. At the moment I don't know any possibility to auto-load packages in PlayerPro on Kernel startup -- for a PlayerPro app with a GUI you can use the Initialization option of Manipulate or DynamicModule to load a package during initialization of the GUI. $\endgroup$ Commented Mar 28, 2013 at 20:12
  • $\begingroup$ Yes, got everything running except the init.m stuff. I hope to hear something back from Premier Support on this. They have escalated the issue to the development group. I'll report back if i get anything. And many thanks for the thoughtful and thought provoking answer. $\endgroup$
    – Jagra
    Commented Mar 28, 2013 at 20:18
  • $\begingroup$ @Jagra: I'd appreciate if you report on the result about the init.m. OTOH I have a feeling that it is not just an incident or bug that both these autoload features don't work, but rather is on purpose for unclear reasons... $\endgroup$ Commented Mar 28, 2013 at 20:29

Try placing your encoded package files at the base of your applications directory without the init.m file present.

In your notebook use Needs["myPackage`"].

A better solution is for you to use the standard application layout for Mathematica Projects. All your files and documentation should be in a folder named after your application. Your init.m file should be in a directory named Kernel which is itself in your applications folder. If you use the Workbench this is the default way of doing things.

If you wish to deploy to PlayerPro you will need to encode your .m package files and your init.m. You will not be able to search your documentation however you can open the nb files that make up your documentation and follow links between them.

  • $\begingroup$ Thanks for this suggestion. It actually (after much fiddling around and testing) works. This provides a workaround to the problem of init.m (Encoded or not), simply not calling a package in the Applications directory. The init.m file not working seems like a bug. If not a bug then one would hope that Wolfram (in documentation or via Premier Support) would provide a reason for why this differs from Mathematica, neither has provided such. +1 $\endgroup$
    – Jagra
    Commented Mar 28, 2013 at 15:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.