[Distutils] Patch to have distutils generate PYC *and* PYO files

Greg Ward gward@python.net
Sun Sep 24 21:50:02 2000


On 22 September 2000, M.-A. Lemburg said:
> It's not as expensive as it sounds... on my machine I can't even
> notice a difference.

I tried it on my machine: spawning a new interpreter to byte-compile
every file in the Distutils is nearly a 100% penalty: 13 sec vs a little
under 7 sec.  So I think it's worth the trouble.

> Right. I don't care about the RPM size at all: bandwidth is
> there, harddisk's are cheap. Size is not as much an argument
> anymore as it was some years ago.

I mostly agree, but turning off byte-compilation should be an option.
(Certainly not the default!)

> > Byte-compiling at build time would also (I think) make it easier to
> > distribute *only* bytecode, for those poor unenlightened souls who
> > somehow think that keeping their source code to themselves will make the
> > world a better place.  (Obviously I disagree with those people, but I
> > don't want to bar them from using the Distutils.)
> 
> Ah, you are forgetting about the few of us who have to make
> a living by writing commercial closed source software, e.g.
> my apps are only shipped with PYO files with doc-strings stripped.

No, I am proposing to change the situation to accomodate people who only
distribute byte-code.  Right now, all built distributions always include
source, because they must pseudo-install the source in order to compile
it.  If we do compilation at build-time, that should make it easier to
distribute only byte-code.  If you want to distribute only byte-code,
you'd have to sneak some code into the appropriate bdist commands to
delete source files after pseudo-installation but before constructing
the archive.

I still think software wants to be free, but I'm not going to shove that 
philosophy down anyone's throat.  ;-)

> Most of the underlying helpers are Open Source though, ie.
> the mx Extensions were written for just this purpose -- not
> only to get a warm fuzzy feeling from community feedback ;-)


> > If we byte-compile at build time, then using the standard compileall
> > module/script is a no-brainer: the build directory is purely the domain
> > of this particular module distribution, so if we blindly walk over it
> > compiling everything, that's just fine.  (Doing that in the real install
> > directory would be quite rude, which is why the current byte-compilation
> > code doesn't use compileall.py.)
> 
> Hmm, the existing logic works just fine -- why change it ?

I can see a couple reasons to change compilation to build time:

  * it just seems right: installation should be limited to copying
    files around, possibly setting modes, and nothing more.  More
    complicated stuff, including compilation, should be done
    at *build* time... that's why it's called "build" time!

  * should make it easier to support closed source distributions

And one good reason not to change it (apart from inertia):

  * makes it trickier to put the right source filename into the
    .pyc file (not that that's being done currently, as you can
    see from a traceback in code installed by a Distutils-generated
    RPM file; the .pyc files refer to /var/tmp/.../usr/lib/python1.5/...
    rather than /usr/lib/python1.5/...)

Am I missing anything?

        Greg
-- 
Greg Ward                                      gward@python.net
http://starship.python.net/~gward/