[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/