Re: Best way to package a python module which is "private" with exposed calling script

[Simon McVittie <smcv@debian.org>]

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