Hi Florian,
I have a few comments on the py26win branch, which I'm planning to merge
this week.
+def check_extract_from_egg(pth, todir=None):
+ """Check if path points to a file inside a python egg file, extract the
+ file from the egg to a temporary directory and return
+ [(extracted path, egg file path, relative path inside egg file)].
+ Otherwise, just return [(original path, None, None)].
+ If path points to an egg file directly, return a list with all files
+ from the egg formatted like above.
+
+ Example:
+ >>>
check_extract_from_egg(r'C:\Python26\Lib\site-packages\my.egg\mymodule\my.pyd')
+
[(r'C:\Users\UserName\AppData\Local\Temp\pyi-win32-0a1b2c\my.egg\my.pyd',
+ r'C:\Python26\Lib\site-packages\my.egg', r'mymodule/my.pyd')]
+ """
+ rv = []
+ components = pth.replace(os.path.altsep,
os.path.sep).split(os.path.sep)
+ for i, name in enumerate(components):
+ if name.lower().endswith(".egg"):
Why are you specifically checking for ".egg"? It is my understanding
that the same applies for ".zip", and more generically for every file
which is in zipformat. Maybe we should just remove this check?
Currently the check/extract seems needed for *.pyd files embedded within
egg files, otherwise pyinstaller's bindepend fails loudly when
encountering such a situation (I think trunk also, so this is really a
workaround for a 'generic' issue).
+ if todir is None:
+ todir = os.path.join(os.path.join(os.environ["APPDATA"],
+ "Python-Eggs"),
+ name + "-tmp")
As a default, why not using the standard Windows temporary directory?
This is the directory also used by pkg_resources/setuptools. So, if the
specific egg was accessed before (not necessarily by pyinstaller), the
extracted contents already exist (pkg_resources puts them there) and can
be used by pyinstaller.
Also, I'm not sure how often this default is used when running a build,
but I would expect PyInstaller to use the "build" directory for this, if
anything.
+ try:
+ manifest = Manifest()
+ manifest.filename = ":".join([pth, str(RT_MANIFEST),
+ str(name), str(language)])
+ manifest.parse_string(res[RT_MANIFEST][name][language],
+ False)
+ except Exception, exc:
+ if not silent:
+ print ("E: Cannot parse manifest resource %s, %s "
+ "from") % (name, language)
+ print "E:", pth
+ print "E:", traceback.format_exc()
+ pass
Maybe we should not silent manifest parsing errors by default. I love
the "silent"/verbose flag for bindpendent, but I guess it's better to
keep errors verbose by default. I would simply remove the "if not
silent" here.
Ok, agreed.
+def check_egg(pth):
+ """Check if path points to a file inside a python egg file (or to an
egg
+ directly)."""
+ components = pth.replace(os.path.altsep,
os.path.sep).split(os.path.sep)
+ for i, name in enumerate(components):
+ if name.lower().endswith(".egg"):
+ eggpth = os.path.sep.join(components[:i + 1])
+ if os.path.isfile(eggpth):
+ # eggs can also be directories!
+ return True
+ return False
Same as above, unless you are specifically checking for .eggs rather
than .zip files for some reason.
Actually, I'm not sure it would apply to anything other than eggs. Are
there situations where *.pyds could be accessed from zipfiles without
.egg extension?
@@ -40,7 +42,7 @@
# to be self-contained. Extra care was put in writing it so
# that it does not share objects/memory with python.dll (which
# it loads).
- env.Append(CCFLAGS = ["/ML"])
+ env.Append(CCFLAGS = ["/MT"])
if flavour == "debug":
# No optimizations
Why is this required? Since there is no threading code in the
bootloader, and no sharing of standard library between the bootloader
and the application+python+pyds, I thought this was not necessary.
Ah, thanks for pointing me to this. I think actually the changes to
Sconstruct can be reverted/ignored, I added them waay back when I was
trying to build the bootloaders myself with MS Visual C++ 2008 Express,
and those changes allowed me to do it. But its not really necessary (I
think the same applies to the changes I made to run.rc and runw.rc).
I didn't go deep into winmanifest, because I don't have enough
competence to follow it... and it works, after all :)
Ok :)
--
Florian Höch
--
You received this message because you are subscribed to the Google Groups
"PyInstaller" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pyinstaller?hl=en.