[Distutils] Byte-compilation revisited

[M.-A. Lemburg]

Greg Ward wrote:
> 
> [I propose a way to deal with closed-source distribution]
> > The idea is that developers could put settings in their setup.cfg that
> > control when to do byte-compilation; I suspect developers who want to
> > distribute closed-source modules will have to do build-time
> > compilation.  Probably the "install" command will need some sort of
> > "don't install source" option, or maybe the build command should have
> > a "blow away source after compiling it" option.
> 
> [Marc-Andre comments]
> > The latter is not very useful, IMHO. I will definitely need the
> > "compile at build time and don't argue about not finding the sources
> > at install time" option ;-)
> 
> The latter option -- "blow away source after compiling it" -- was
> proposed because it would be easier to implement than "don't install
> source".  The "install_*" commands generally boil down to a recursive
> copy from the build tree to some installation director(y|ies).  The less
> work done there, the better, as figuring out the installation dirs is
> hard enough.  (Hence my preference for compiling at build-time.)  If we
> do things this way:
>   * copy source into build/lib
>   * byte-compile source
>   * blow it away
>   * install it
> 
> then the install commands remain fairly simple.  If not, we have to do
> something to exclude .py files from the "install" recursive copy.

Uhm, I only wanted to prevent the install command from producing
errors in case it cannot find the .py files to install (it should
suffice just being able to copy the .pyc/o files). 

Basically, the .py files should be in the source archive and be used to
build the binaries. The binaries should then optionally only include
the .pyc/o files and the install command or RPM shouldn't care much
about not finding .py files...

> > Looks ok , except that I would pass the Python filenames through
> > os.path.abspath() before writing any externally run scripts...
> > both to work around possible security problems and to make sure
> > the shell finds the right files.
> 
> Hmmm, that's probably wise.  [ ... far too much time passes ... ]
> No wait, it breaks the "dfile" argument in certain circumstances,
> so that .pyc files created at build time have the wrong source
> filename encoded in them.  Bother.  This will be tricky to fix,
> so I'm gonna punt on it.

Ok... but please make sure that the temporary script uses an
absolute name and that the name of that file cannot be guessed.
Otherwise, you'd open up a /tmp security problem here which could
be used to trick distutils into executing code which wasn't
generated by it.

Perhaps you should pipe the program text to a Python interpreter
instead... this would be the most secure option.

We really need a sys.set/getoptimization() API in 2.1...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/