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.
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...