Include a PYTHONPATH extension allowing for user-space packages.

[freakboy3742]

What is the problem or limitation you are having?

The stub app currently sets a PYTHONPATH that includes the app and app_packages paths, plus the stdlib.

These paths are all inside the application bundle, which is a code-signed location.

If a user wants to add additional files to the PYTHONPATH (e.g., if you were building a "Jupyter Notebook" app, and wanted the user to be able to access user-installed packages), you can't install that code into app or app_packages.

Describe the solution you'd like

The stub app should include an Application Support folder as part of the standard app path.

Following the guidance of this document, this should be something like:
~/Library/Application Support/com.example.myapp/user_packages

Describe alternatives you've considered

Don't allow user-installed packages.

Additional context

Looking in an actual application support folder, there's some variation between the use of Formal Name and bundle as the app-specific identifier - i.e., ~/Library/Application Support/My App/user_packages. Using the bundle ID seem least likely to cause collisions.

Once this feature lands, the app template will need to be updated with a new binary.

[mhsmith]

I'm not sure if it's worth building this into the template, because modifying sys.path at runtime works perfectly well. And if you were writing a notebook app, you'd need to manage multiple environments, so having a single hardcoded user_packages directory wouldn't be good enough anyway.

There's also no need for the template to help locate the support folder, as there are already APIs for that in higher-level libraries such as Toga or platformdirs.

[freakboy3742]

It's true that a user could use runtime modification of sys.path; however, I was thinking this could be a helpful convenience - one less thing for an end user to write (and potentially get wrong). It doesn't hurt to have a path that doesn't exist on the PYTHONPATH; and if we can guarantee that there's always a user-writable space on the PYTHONPATH, we can document that convention, and potentially provide the helper to run pip and install into that path (although, thinking about it, I guess we could make that briefcase-pip package have an init() method that sets the PYTHONPATH, and document that before you use bpip.install() you have to run bpip.init()...)

I'll agree the "Jupyter notebook" isn't a good example - you're right that would need to be a "document specific" pythonpath - I was using it as an example of something that obviously needs an importable user path. The "in practice" use case I'm thinking of is more of a "plugin" type arrangement - e.g., a code editor with plugins.