On Sat, Mar 24, 2001 at 08:25:57AM +0200, Moshe Zadka wrote: > On Fri, 23 Mar 2001, Gregor Hoffleit <[EMAIL PROTECTED]> wrote: > > > currently, our Python packages mostly ship .py files and compile them into > > ..pyc files at run time in order to save space in the debs. > > > > There's no reason, though, to keep the .py files on machines that only > > deploy software[1] > > Yes there is --- tracebacks look awful without .py's. > Fact is, loading of only .pyc's isn't officially supported by Python. > (the official Guido position is "Python is an open-source language. I'm > not going to waste my time *helping you* not distribute source")
Ok, that argument bought me. I still see some cases where removing .py files is reasonable (if space is very tight), but with these things in mind, it's certainly nothing which should be encouraged by the packages. > I do think we need somewhere where all the .pyc's are "registered", so when > a new version of Python comes along, it can recompile them, since pycs > are not compatible across versions. That's an interesting point. The obvious solution would be to add strict dependencies (something like "Depends: python2-base (>= 2.0), python-base (< 2.1)"). This way, a new version of a package had to be installed if a new upstream version of python2-base was installed, and subsequently the .pyc/.pyo would get rebuilt for this package. I realize only now that this is a major issue when installing two versions of Python in parallel. Gregor