Produce .pyc without execution

[François Pinard]

Michael Hudson <mwh21 at cam.ac.uk> writes:

> I think installing .pyc's but not .py's is mischevious, if only
> because meaningful tracebacks are nice.

We have to be careful in our search for virtue.  Richard Stallman always
wanted packages to install un-stripped binaries, for reasons like above.
The disk space it takes, as well as the principle, is not very acceptable
for a lot of users, and Linux packagers defeat it quite systematically,
so far that I know.  It surely required a lot of doing and many fights (I
do know some of them :-) before the thing could be done with more ease than
difficulty within GNU, and I've been told that some of the last problems are
going to be solved in the next release of Autoconf, if not already.  I do
not follow this file closely anymore, now, as helping GNU is too exhausting.

My opinion is that quality packages should not traceback anyway, and
rather produce their own user-oriented diagnostics.  The installation
process should be oriented more towards users than towards debugging,
for anything else than alpha software.

Even for Emacs, Linux packagers set things so LISP sources are optional.
Oh, no doubt that having sources installed is a good things for many users,
but in the long run, we are going to have more and more users who are not
especially programmers, or not especially interested in the inner details
of everything they use, so we should silence our natural proselytism :-).

> > What would be ideal is a way for `compile_dir' to produce `.pyc' in
> > the build hierarchy directly from the source hierarchy at `make all'
> > time, and that `make install' just move these ready `.pyc' files into
> > the installation directories.

> It shouldn't be all that hard to adapt Lib/py_compile.py &
> Lib/compileall.py as appropriate to effect this.

I hope that people responsible for these packages are listening! :-)

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard