Something to keep in mind is that it’s somewhat of a “power user” kind of thing in Sublime to seek out and edit a sublime-settings file yourself (say with a file browser or via View Package File from the command palette) and generally that would be exposed by adding an item to the menu and/or the command palette that opens the appropriate file for you.
So in that sense, it may be enough to have two settings files; one that’s “hidden” and one that’s "public’; the hidden one would be a settings file stored in the User package but not exposed and the other one would be made more traditionally available. In that scenario you’re more or less setting up a power user with the ability to easily tweak the file (which they could probably figure out anyway) without going to any extra work.
On the flip side, something in favor of not storing the file in the User package is that it’s fairly common to syncrhonize your User package across multiple computers (including multiple operating systems) to keep all the copies of Sublime you use running the same. In such a case, storing configuration like the one you’re mentioning here may be a bad thing if the data it contains is somehow machine specific.
More or less, yep. Presuming that you obtain packageDir as something like os.path.join(sublime.packages_path(), "MyPackageName") (basically, you don’t want to write directly to sublime.packages_path()).
An alternative is to use sublime.cache_path() instead; that keeps things outside of the Packages folder but still associated with Sublime itself.
If you use packages_path(), you should definitely use a folder named for your package, since that’s essentially your “namespace” and is an area that nothing else should be touching. In the case of cache_path() it’s generally a good idea to do the same, for similar reasons.
In either case you also need to take the step of making sure the folder exists. If you’re working on your package locally, then that’s definitely the case. However if you distribute your package via Package Control at some point, it generally ends up getting installed as a sublime-package file instead (unless you tell Package Control not to do that), in which case the folder won’t be there unless you create it first,
The sublime.load_resource() method can be used to load the content of a package (wether it is in a folder or inside of a sublime-package file), so you could use that in order to load the file when you need to. There’s no real analoge for saving files into your package though, since generally speaking the most common things to be saved into a package would be settings (and that happens automatically).
To use it, you could do something like sublime.load_resource("Packages/MyPackage/appPaths.json") to give you the content of the file in one call (or load_binary_resource(), if the file is not text). It will throw an exception if the file can’t be found. You can also use sublime.find_resources() in order to determine if the file exists; sublime.find_resources("appData.json") would return a list of every file by that name that exists in a package, for example.
Something to note is that load_resource() will work with files from the Cache folder, but that’s sort of an implementation detail that may or may not go away, so it may not be a good idea to rely on it.
One last thing is that rather than loading the file in your commands, you could define a plugin_loaded() function in your plugin and load the file there. That method gets called every time a plugin reloads, which is the first time it’s loaded at startup, whenever you modify it, and when the package that it’s in gets removed from the ignored_packages setting. Assuming the data doesn’t change very often, that would let you load the file once instead of every time a command that needs it is executed.
