Re: Questions about packaging a python script
-----BEGIN PGP SIGNED MESSAGE-----
Sudhakar Chandrasekharan <email@example.com> writes:
> 1. linbot.py and associated *.py files need to be installed in the same
> directory. I was thinking of installing these under /usr/lib/linbot/
> Is this the Right Thing to do?
Hmm. How about /usr/lib/python1.5/site-packages/linbot? If you put
an __init__.py file (even a zero-length one) in there, the contents
will be importable as "linbot.<whatever>"; either way, it is still a
suitable location for Python stuff of all sorts.
If you don't use the site-packages directory, I would guess that
/usr/share is better than /usr/lib, given that Python code is
> 2. I will ln -s /usr/lib/linbot/linbot.py /usr/bin/linbot Is this
> compliant with the Debian packaginh policy? Should the symbolic link be
> relative? I don't think it should be absolute.
Well, I just did this in one of my packages, and lintian said it
should be relative :)
I couldn't find anything in the policy forbidding symlinks like this,
and it would appear that a few other packages use them. I figure that
as long as you install the target of the symlink in the same package,
or depend on the package that install it, you are fine.
(My package, by the way, was palmpython -- it is structured as a
Python hierachial package, and it contains a few modules which are
intended to be used both as part of the package and from the command
line. This is a fairly common practice in Python programming, so
symlinks are inevitable.)
> 3. Should debian/rules or makefile create the symbolic link? Or should
> that part be done by postinst?
Make it during the build process; you can put symlinks in a package,
so why make the postinst any longer than it has to be? (Don't forget
to borrow the postinst and prerm from another Python package, so you
can get the .py files compiled properly.)
> 4. If I want to set / appened to an environment variable (PYTHONPATH)
> globally for the entire system, where (which files under /etc) would I
> do it? Should postinst do it? If so, there is the whole problem of
> variations between the numerous shells. Or should I leave it to the
You could, I suppose, use a .pth file (read the description of the
Python packaging system for details; the relevant material is
somewhere on www.python.org. I don't remember exactly how .pth files
work.). However, my personal feeling is that you should probably
leave the python path alone, and choose another alternative for making
the required libraries available to the Python scripts:
- you could put the executable script in the same directory as the
libraries, and then symlink it to an appropriate place in /usr/bin
(I hope this is okay policy-wise.) The interpreter will pick up
the actual location of the script, and automatically add the
current directory to the path.
- you can put the files in a directory that is already on the path.
/usr/lib/python1.5/site-packages is the standard place for this.
- you could put the executable stript itself in /usr/bin, and put
all the modules somewhere on the Python path. (A symlink is
probably better, though.)
By the way, are you on the debian-python mailing list? It hasn't
gotten any traffic yet that I know of, but I gather it is supposed to
be used for discussing Python-related stuff...
Rob Tillotson N9MTB <firstname.lastname@example.org>
-----BEGIN PGP SIGNATURE-----
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
-----END PGP SIGNATURE-----