FHS location for locally-compiled bytecode

[Ben Finney]

Floris Bruynooghe <floris.bruynooghe at gmail.com> writes:

> Hmm, not sure if Java is comparable.  The issue with Python is that
> the source code can be run by the interpreter too

Not really true. What happens is that the Python interpreter will
compile the source code just-in-time, and then run the resulting
bytecode.

In other words: the Python source code is never executed, it is always
the bytecode that is executed; sometimes the compilation happens
just-in-time.

In this, it is unlike (for example) Bash shell input, which is
interpreted at run-time directly from the source code.

> Possibly better to compare it to Lisp?

Yes, and indeed I tihnk the same issue exists for Emacs lisp files:
many distributions pre-compile them (at package install time) to
bytecode files ready for execution. Where should such files be stored
such that the FHS continues to be consistent, simple, logical, etc.?

> The architecture independed remark is a good point. I'd be
> interested to know where other distributions tend to put these
> bytecode files currently.

Agreed.

> In Python's case Debian seems to make a mess currently by spreading
> it out in /usr/lib/pythonX.Y (next to the source, this used to be
> the de-facto standard a while ago) and /var/lib/python-support.
> What's annoying about this IMHO is that Debian's sys.path is
> different from a "normal" one.

My initial motivation was attempting to resolve this mess. So far it's
led to trying to interpret, or perhaps clarify, the FHS on this issue.

-- 
 \                 “What's another word for Thesaurus?” —Steven Wright |
  `\                                                                   |
_o__)                                                                  |
Ben Finney