Names["PalmerPractice`TestPackage`*"]

Or

?PalmerPractice`TestPackage`*

David's dust story metaphor is right on. There are so many things an inexperienced user can find to do wrong, that finding the one right way to do something can take a long time. In this case, I am happy to report that David's system for managing notebooks and package files in projects is now working for me. I can't say why it didn't work the first time, but it is now working for two test projects, initializing a different package file in each.

In Windows, at least, one can right click in an open Folder and create new files from a New menu. There are many types of files there but only one Wolfram file type, a Wolfram Notebook. Maybe there is some difficulty in it, but it would be really nice if WRI could figure out how to add a Wolfram Package to this menu. This would be the most convenient way to create new packages. (And notebooks also.) One might not even have a convenient Mathematica notebook open to use the Mathematica File/New menu. It's really much more convenient and logical to create new files from the folder that will contain them.

I like that idea, too.

I think Wolfram could improve their design and information.

In Windows, at least, one can right click in an open Folder and create new files from a New menu. There are many types of files there but only one Wolfram file type, a Wolfram Notebook. Maybe there is some difficulty in it, but it would be really nice if WRI could figure out how to add a Wolfram Package to this menu. This would be the most convenient way to create new packages. (And notebooks also.) One might not even have a convenient Mathematica notebook open to use the Mathematica File/New menu. It's really much more convenient and logical to create new files from the folder that will contain them.

So I usually end up creating a Mathematica Notebook, changing the suffix to .m and brushing the warning aside. But that creates the package file with the Notebook statement in it, which also needs to be brushed aside. Why is it necessary to put any cell in the new package file? When you create a new notebook it doesn't contain some default cell. Why should a package file. (Users should be aware that a package file can also contain titles, sections and text cells just like a notebook.)

There is also confusion over whether a package file should have a .m or a .wl suffix. Are they completely interchangeable? Will .m be deprecated? I'm not totally certain but I seem to recall that at some point .wl could not be used - I think it may have been as an init.wl file.

All of this creates a little dust storm that envelops the user, especially those new to writing packages. So guys. why don't you fix it and clarify it?

Gary,

I have a tutorial on my web site on setting up applications with packages. A Mathematica Style. This is, I believe the standard method WRI has set up for private packages and applications.

I implemented your application and tested that it works. It took about 20 minutes. Here is the file structure used by the application.

$UserBaseDirectory/Applications/
     PalmerPractice/
         Kernel/init.m
         DevelopmentNotebooks/TestNotebook.nb
         TestPackage.m

I've attached the TestPackage.m, TestNotebook.nb and init.m notebooks. Perhaps you could set up the folder structure and then insert the notebooks.

With this structure it is not necessary to use SetDirectory. Mathematica will automatically find everything in the application. You can load the package from anywhere. Even though you have only one package, I set it up so it could accommodate a number of packages. The package is loaded with

<< PalmerPractice`

When Mathematica see that, it automatically reads the init.m file in the application, which does the actual loading of package files.

On my Windows 7, Mathematica 10.4.1 system this all works properly and it should also work on your system.

Attachments:

It should work for both Windows and Apple. Is the TestPackage.m directly in the PalmerPractice folder?

I also want to add that you shouldn't have to add the package to the $Path. Mathematica automatically looks at that location. So I suspect you don't have the correct folder structure.

I did find an error in the init.m file that I posted. Apologies. it had the statement:

Get["PalmerPractice`TestPAckage`"]

and it should have been:

Get["PalmerPractice`TestPackage`"]

Which makes me wonder why it still worked for me. It appears that on Windows 7 the string in the Get statement is not case sensitive.

I"ve sold 100's of applications with packages using this structure and they all have been able to install and use the packages. And palettes and stylesheets automatically appear on their menus and the documentation is accessible. All they had to do was to unzip into their $UserBaseDirectory/Applications folder.

So I'm a bit at a loss why this is not working for you, even with a simpler case.

Mathematica knows where to look because of one of the entries on the Path expression. Is it possible that you have somehow changed your Path definitions? Also in GlobalOptions, File Locations, NotebookPath there is an entry that points to:

FrontEnd`FileName[{$UserBaseDirectory, "Applications", Blank[], 
  "FrontEnd", "Palettes"}]

And on the Path expression there is an entry:

C:\Users\djmpark\AppData\Roaming\Mathematica\Applications

Has one of these somehow gotten changed on your computer? Maybe you could reinitialize your options by holding down Ctrl+Shift when starting Mathematica.

The simplest approach is to give packages a binary name: the application name "PalmerPractice" and the package name "TestPackage". So the BeginPackage statement would be:

BeginPackage[""PalmerPractice`TestPackage`"]

When a user just reads in an application such as:

<< PalmerPractice`

Then it looks to the PalmerPractice/Kernel/init.m file to read in all the packages you might have in the application, and do any other special initializations. That's how it's supposed to work, and how it always has worked for me and people I've sent applications. On Windows and Apple. So it is a bit of a mystery as to what is happening on your system.

That's very strange; there are several things here that shouldn't happen.

First off, your "hello" test definitely won't work the way you expect: You define hello with Set (not SetDelayed), so if everything is working as it should, you'll get the output of hello once during package loading and then never again. If that's not what's happening, then the package wasn't loaded.

Secondly, hello and v live in the "Development" context, they should not show up in "Global" at all.

Could you try the following things and let us know what happens?

First, to find out if the package was loaded at all: Are hello and v marked in blue (i.e. as unknown symbols), or are they black? Did you do all of this on a clean Kernel, or were there possibly definitions of hello and v already floating around? Can you evaluate $ContextPath both before and after trying to load the package (on a fresh Kernel), and let us know what it returns?

Also, can you try the following to see if Mathematica is really finding the correct package file at all? (Maybe there are other packages with the same name higher up on the path.)

FindFile["Development`"]

Does the package work if you put the notebook and the package into the same directory, SetDirectory to that place, and then use Get["Development.m"]? (i.e. load it with its file name rather than the context)

Your question title is specifically about Mathematica 10; did you have this problem with previous versions as well? (You mention having had this problem for years, so I assume it didn't appear with the last upgrade.) Have you experienced the problem on different installs, either when re-installing for some reason or on different computers?

Is this a problem you have with all and any packages, or just your own? Can you use built-in packages? Can you use third-party packages?

Is there any chance that there's something weird in your $UserBaseDirectory/Kernel/init.m file? Does $Path look okay?

(Also, not really a problem, but why do you set your directory to the package directory?)

Edit: Oh, one more minor thing: You forgot a context mark at the beginning of the Private context; it should be:

Begin["`Private`"]

(But your version didn't break the package for me when I just copied and pasted, so it's not the source of your trouble...)