[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] Mysterious Included Files
On Feb 14, 2005, at 23:00, Kris Schnee wrote:
Bob Ippolito wrote:
No, py2exe does not do that. It starts from your main script, and
analyzes Python bytecode and looks for import statements (via
modulefinder), then it tries to find the modules in a similar way to
how Python finds them, and it says they should be included. If you
don't want something included, don't import it! You are somehow
actually using this code from your other projects, because there is
no other way it would find it!
When I run py2exe for this program, none of my own files appear in the
list of things it's compiling, yet they show up in the library.zip.
And this is when I compile one of the OpenGL NEHE tutorial scripts,
which I'm sure doesn't use (for instance) "virtual.py," a piece of
code I never released and never included in the tutorial.
Maybe it has something to do with "setup.py"?
# setup.py
from distutils.core import setup
import py2exe
#setup(name = "charm", py_modules = ["ljcharm"], scripts = ["charm"])
setup(console=["lesson08-k.py"])
The "charm" line is from LJCharm, a program I tried to compile
earlier; the line is commented out in the original too.
Weird. I guess at worst I could unzip the library and make a new one
without the extra files.
The only code in setup.py that should influence the operation of py2exe
are modifications to sys.argv, sys.path, and anything that ends up in
the setup(...) function. Even if you imported the charm script from an
uncommented line in setup.py, it wouldn't matter because setup.py is
not one of the scripts scanned.. unless, of course, the target script
is importing something named setup. Commented lines should never
effect py2exe's operation in any way whatsoever, it doesn't look at the
source code, and # comments don't even end up in bytecode!
>>> import dis
>>> dis.disco(compile('#import foo', '<test>', 'exec'))
0 0 LOAD_CONST 0 (None)
3 RETURN_VALUE
>>> dis.disco(compile('import foo', '<test>', 'exec'))
1 0 LOAD_CONST 0 (None)
3 IMPORT_NAME 0 (foo)
6 STORE_NAME 0 (foo)
9 LOAD_CONST 0 (None)
12 RETURN_VALUE
It may be the case that something in PyOpenGL or the target script is
importing something named virtual, and modulefinder ended up finding
your module rather than the one it was supposed to find (or not find).
I think this scenario is rather unlikely, though.
A more likely scenario is that in the same directory, you created a
py2exe based setup.py for a script that *did* somehow use virtual,
built it, and then you modified the setup.py script to package a script
that *did not* use virtual. If run again, without cleaning the
build/dist directories, py2exe will potentially include everything it
found on the first run in addition to what was found in the second run.
IIRC, it is not terribly intelligent about housecleaning (py2app is
only marginally smarter about this).
Whenever you make non-trivial modifications to any distutils setup.py
or its targets you should *always* clean your build and dist dirs (dist
may not be relevant for using distutils without packaging extensions).
-bob