Re: /usr/lib vs. /usr/share
Harry Henry Gebel <hgebel@home.com> writes:
> On the other hand, we could put the .py files in /usr/share if we moved the
> generated .pyc/.pyo files to /usr/lib (can (should?) compileall be modified
> to do this automatically?) We would keep sys.path to the standard, and
> since the .py files would no longer be in sys.path they would no longer be
> executable and would qualify for /usr/share . I think a system similar to
> this is how the emacsen allow one Emacs mode package to be used by several
> Emacs versions.
Yes - the Emacs packages actually work by copying the .el files into a
temporary directory and compiling them there. For Python, a better
solution would be a modified version of compileall, maybe under a new
name. (compileall_debian?)
By changing the call to py_compile.compile(), the byte-compiled file
can be put in any directory or directories, e.g. both of
/usr/lib/python1.5/site-packages/foo.pyc and
/usr/lib/python2.1/site-packages/foo.pyc, without the source foo.py
file being anywhere in sys.path.
>From a few quick tests, it seems that Python 2.0 remembers the path
for the source file, so it can still fill in a traceback correctly
even when the source isn't in sys.path.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Quiet, you'll miss the humorous conclusion."
Reply to: