On Mon, 06 Feb 2017 at 16:43:32 -0500, Thomas Nyberg wrote: > What I would ideally like is for the module > code to be put somewhere off the regular system path and then have the > binary "know" how to find it.
If you do this: /usr/ ├── bin/ │ └── script → ../share/mypackage/script (symlink) └── share/ └── mypackage/ │ ├── module/ │ └── __init__.py └── script then the script will automatically put the directory containing the script's real file, in this case /usr/share/mypackage, at the beginning of sys.path. The offlineimap package is a good example of relying on this technique: /usr/bin/offlineimap is actually a symlink to /usr/share/offlineimap/run to avoid colliding with its module, which is also called offlineimap. I think a script named "run" is quite a common convention for doing this? Or if you have a convention of using dash-separated-words for the script and underscore_separated_words for the library module, they won't collide anyway. game-data-packager-runtime (the launcher/frontend part of game-data-packager) works similarly, although for historical reasons game-data-packager itself is a shell script that sets PYTHONPATH. This is not portable to platforms that don't have symlinks (hello Windows) or platforms where argv[0] isn't always absolute (obscure Unixes?) but for the purposes of Linux, and probably also *BSD and Hurd, it's fine. S