Problem with PlayerPro recognizing a proprietary package

Question

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 **)
Get["myPackage`"]

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:

.../MathematicaPlayerPro/Applications

.../MathematicaPlayerPro/Kernel

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["myPackage`"]

$Failed

Get["Users/username/Library/MathematicaPlayerPro/Applications/myPackage`"]

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

I have also tried:

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

$Failed        

Needs["myPackage,"Users/username/Library/MathematicaPlayerPro/Applications/myPackage`"]

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

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 9.0.1.0. 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.

Answer 1

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

Get["Users/username/Library/MathematicaPlayerPro/Applications/myPackage`"]

But the return value of

Get["myPackage`"]

and the message of

Needs["myPackage`"]

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:

BeginPackage["test`"]
testfun::usage="testfun does nothing";
EndPackage[];

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:

Encode[
   "C:\\Users\\albert.retey\\Desktop\\test.txt",
   "C:\\Users\\albert.retey\\Desktop\\test.m"]

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

(*!1N!*)mcm
j<hTJue'P+lKh]7t>X#r/N5>m^c0Q )K,<@X>.5bPbTY_m,n@1#W5cPbTYS)Q6i.XXJ.p1
2!rF:tH|qLWBuA`Ua'  

Now create a new notebook with the following content:

Get["C:\\Users\\albert.retey\\Desktop\\test.m"]

?testfun

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:

Quit[]
AppendTo[$Path, NotebookDirectory[]];
Needs["test`"]

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:

Quit[];
Get["test`"]
?testfun

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.

Answer 2

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.