Re: [pygame] Executable creation blues
Bob Ippolito wrote: Since when? py2exe and py2app are almost the same until you start using platform specific features. You may be right about that. I just tried to check by visiting the websites of both to consult the docs, but from what's there, it's quite hard to tell. Neither of them seems to have what I woud call a proper set of documentation that explains all the options properly. -- Greg
Re: [pygame] Executable creation blues
Bob Ippolito wrote: tkinter is imported (conditionally) by a few things you wouldn't normally expect, such as PIL and pydoc. My bet is on PIL. It may have been something like that. But if I explicitly put it in the excludes list, I would expect it to trust that I know what I'm talking about. That didn't seem to be happening. -- Greg
Re: [pygame] Executable creation blues
Luke Paireepinart wrote: I'm struggling to grasp py2exe's arcane innards, as it's changed significantly since I last used it, and so far it just doesn't work. I'm sure I can eventually grovel through source and get it to work, but there's got to be something better! Except I can't find anything! Py2app? Mac only. Pypack? Based on a non-robust premise, and thus doesn't work for me. What exactly is the problem you're having with py2exe? Afaict you just make a couple-line setup.py file and it just works Did you try the py2exe instructions on the pygame website? Yes, I've tried that, but unfortunately those few simple lines aren't enough. The resulting .exe can't find all of it's needed parts, and apparently includes a vast array of stuff that isn't needed. Some of the missing errors I'm getting are from code I never use, burried deep within libraries I need, e.g. numpy. I've had less trouble getting crossplatform C++ code to statically compile than I'm having sorting this out for just Windows. -Jasper
Re: [pygame] Executable creation blues
Jasper wrote: Luke Paireepinart wrote: I'm struggling to grasp py2exe's arcane innards, as it's changed significantly since I last used it, and so far it just doesn't work. I'm sure I can eventually grovel through source and get it to work, but there's got to be something better! Except I can't find anything! Py2app? Mac only. Pypack? Based on a non-robust premise, and thus doesn't work for me. What exactly is the problem you're having with py2exe? Afaict you just make a couple-line setup.py file and it just works Did you try the py2exe instructions on the pygame website? Yes, I've tried that, but unfortunately those few simple lines aren't enough. The resulting .exe can't find all of it's needed parts, and apparently includes a vast array of stuff that isn't needed. Some of the missing errors I'm getting are from code I never use, burried deep within libraries I need, e.g. numpy. I've had less trouble getting crossplatform C++ code to statically compile than I'm having sorting this out for just Windows. I'm sensing some python-hatin' going on here ;) Let me just point out that cpython is meant to be installed on the target machine once, not redistributed. Since it wasn't designed for that, trying to make it into a nice, neat little package doesn't work all that well. I just don't want you to think less of python because a 3rd-party tool's giving you trouble. I'm not sure why you're having problems but your hunch that Numeric and Numpy are conflicting sounds reasonable. Why do you have both installed, by the way? -Jasper
Re: [pygame] Executable creation blues
Hey Jasper, It does seem like an obscure and difficult problem, but at least it seems to be one a lot of people are having :) the py2exe mailing list archive had this snippet for your exact problem: I resolved that issue by adding the file ...\Python24\Lib\site-packages\numpy\core\_internal.pyc in ...\test\dist\library.zip\numpy\core. ...as far as a solution that doesn't require hand-copying though, there was this follow-up in the mailing list, which supposeded has 2 working py2exe setup scripts in it: http://www.mail-archive.com/numpy-discussion@lists.sourceforge.net/msg02062.html also, the py2exe and/or numpy mailing lists may be good places to post your errors in order to get some up-to-date and educated help, if you haven't done so already. also, here's two more numpy and py2exe problems + hack fixes from the py2exe wiki, I figured I'd embed them here in case they pop up for you after you get past the _ARRAY_API problem -- If you're getting No scipy-style subpackage 'xxx' found in c:\...\library.zip\numpy. Ignoring, try --skip-archive option. If you're using numarray and numpy together, be aware that they both have a _sort, and py2exe gets them confused. After py2exe creates the dist directotry, copy numpy/core/_sort.pyd and numarray/sort.pyd to their respective locations in the dist. -- On 9/28/06 Jasper [EMAIL PROTECTED] wrote: I've had less trouble getting crossplatform C++ code to statically compile than I'm having sorting this out for just Windows. Haha... everybody has their success stories :) If you've done a lot statically compiling different crossplatform C++ code libraries on a windows platform, I'd be suprised if you never had any problems with STL and iostream inconsistencies, or different files fighting over new... not to mention the garbage you'll get just changing visual studio versions (if you ever do that). I'll take python with it's buggy and imperfect code+interpreter packaging over the alternatives anyday Luke wrote: I'm sensing some python-hatin' going on here ;) Let me just point out that cpython is meant to be installed on the target machine once, not redistributed. you are right in that python is wonderful at building packages for extension libs and all that, but I say designed shmesigned - what matters is what is tested and what works. py2exe is actively maintained, and as long as windows users are still out there trying to get good solid packaging taken care of, all problems will be solved for getting good windows distribution. Since it wasn't designed for that, trying to make it into a nice, neat little package doesn't work all that well. I just don't want you to think less of python because a 3rd-party tool's giving you trouble. I completely disagree - packaging and distribution is an essential part of developing anything. If you've got a great language, but you can't distribute it to your customers, by all means, blame the language distribution. Better yet, work to help make its packaging better. I'm not sure why you're having problems but your hunch that Numeric and Numpy are conflicting sounds reasonable. Why do you have both installed, by the way? I think the better question would be why pygame has had (thankfully optional) dependencies on a pacakge that hasn't been maintained for years (namely numeric) for as long as it has... (hope I'm not being rude here, but I do find the numeric dependency to lame to be worth using the surfarray sndarray stuff)
Re: [pygame] Executable creation blues
I'd still like to hear why the original poster found PyPack unsuitable, (so that I could improve it), since it, for example, gets around both of the numpy/Numeric problems posted by Brian. -- Sami Hangaslammi
Re: [pygame] Executable creation blues
Luke Paireepinart wrote: I'm sensing some python-hatin' going on here ;) Let me just point out that cpython is meant to be installed on the target machine once, not redistributed. Since it wasn't designed for that, trying to make it into a nice, neat little package doesn't work all that well. I just don't want you to think less of python because a 3rd-party tool's giving you trouble. No, as I love working in Python, and loath C++. Although Python is my favorite language, I can still see it's warts. The distribution tools available really are pretty bad, and it's not so much that Python wasn't designed for it, but rather that barely anyone ships Python .exe's and so it's rare that anyone notices just how bad this aspect is. Anyway, my reason for posting wasn't so much to complain about py2exe, but just hoping that someone would know of something better. I'm not sure why you're having problems but your hunch that Numeric and Numpy are conflicting sounds reasonable. Why do you have both installed, by the way? Because I prefer to use numpy, since it's replaced Numeric (which is now defunct), but I also use pygame, which uses Numeric. Fortunately, I'd just begun to switch to numpy and it was easy enough to switch back to Numeric, but having to change my code to get it to work isn't encouraging.. Now I'm working on this one, which I vaguely recall coming up in Pypack discussion before: Traceback (most recent call last): File legacy.py, line 9, in ? File Realms\Myth\Client\client.pyc, line 16, in ? File Realms\Myth\Client\theme.pyc, line 8, in ? File Realms\Util\surfaceTexture.pyc, line 4, in ? File OpenGL\__init__.pyc, line 18, in ? File OpenGL\__init__.pyc, line 14, in __set_attributes IOError: [Errno 2] No such file or directory: 'c:\\BrassGolem\\Realms\\dist\\lib\\shared.zip\\OpenGL\\version' -Jasper
Re: [pygame] Executable creation blues
Sami Hangaslammi wrote: I'd still like to hear why the original poster found PyPack unsuitable, (so that I could improve it), since it, for example, gets around both of the numpy/Numeric problems posted by Brian. Partly because it apparently didn't like having an entry script somewhere other than the root directory (although I didn't fiddle around with this much so I could easily be missing something), but mostly because I didn't think the method of tracing execution to find imports was robust, in particular if you have dynamic imports. In retrospect I bet py2exe doesn't handle this either, so I'll give Pypack another try.
Re: [pygame] Executable creation blues
On 9/28/06, Jasper [EMAIL PROTECTED] wrote: Sami Hangaslammi wrote: I'd still like to hear why the original poster found PyPack unsuitable, (so that I could improve it), since it, for example, gets around both of the numpy/Numeric problems posted by Brian. Partly because it apparently didn't like having an entry script somewhere other than the root directory (although I didn't fiddle around with this much so I could easily be missing something), but mostly because I didn't think the method of tracing execution to find imports was robust, in particular if you have dynamic imports. In retrospect I bet py2exe doesn't handle this either, so I'll give Pypack another try. Your reasoning is totally backwards. py2exe (and just about everything else) uses a less robust way of tracking imports -- it examines bytecode, which will never find dynamic imports. Tracing execution will generally find all imports, so long as your code isn't pathologically dynamic. Analyzing bytecode is completely safe, automatable, deterministic, and relatively fast.. where running an application to see what it does is generally none of those things. That's why py2exe and related tools generally default to using bytecode analysis despite it being flawed in pathological cases. py2app has built-in workarounds for known pathological cases in the stdlib and many popular libraries, but I don't know if anything like that exists in py2exe yet. -bob
Re: [pygame] Executable creation blues
Bob Ippolito wrote: On 9/28/06, Jasper [EMAIL PROTECTED] wrote: Sami Hangaslammi wrote: I'd still like to hear why the original poster found PyPack unsuitable, (so that I could improve it), since it, for example, gets around both of the numpy/Numeric problems posted by Brian. Partly because it apparently didn't like having an entry script somewhere other than the root directory (although I didn't fiddle around with this much so I could easily be missing something), but mostly because I didn't think the method of tracing execution to find imports was robust, in particular if you have dynamic imports. In retrospect I bet py2exe doesn't handle this either, so I'll give Pypack another try. Your reasoning is totally backwards. py2exe (and just about everything else) uses a less robust way of tracking imports -- it examines bytecode, which will never find dynamic imports. Tracing execution will generally find all imports, so long as your code isn't pathologically dynamic. In hindsight I see this, and posted that too quickly (I'm really itching to get this working). IMHO you're wrong that code needs to be pathologically dynamic to use dynamic imports. I find it an entirely reasonable way to load dynamic code and content. I don't make much use of it now, but plan to as an easy means game modding. That said, this should be encapsulated enough that it'd be easy to manually add. I'll give Pypack another try. -Jasper
Re: [pygame] Executable creation blues
On 9/28/06, Greg Ewing [EMAIL PROTECTED] wrote: Bob Ippolito wrote: The other pathological case is where a C extension invokes the import machinery, which happens a bunch in the stdlib (e.g. importing codecs, warnings, etc.). py2app has complete coverage of these scenarios in the stdlib (as of Python 2.4, anyway), but I don't believe that py2exe does. Seems like the various packager development efforts could benefit from more cooperation with each other. All the platform-independent knowledge about how to find dependencies ought to be factored out and made available in a way that all packagers can use. I already did this with modulegraph. It's up to other people to use it though, I don't have the time or interest to make patches for other people. Deciding on a common user interface for packagers would help, too. Currently each one has its own unique way of going about things. Since when? py2exe and py2app are almost the same until you start using platform specific features. -bob
Re: [pygame] Executable creation blues
Greg Ewing wrote: Jasper wrote: The resulting .exe can't find all of it's needed parts, and apparently includes a vast array of stuff that isn't needed. This is tangential to the OP's problem, but last time I tried to use py2exe, it seemed to insist on including tkinter in the executable, even though my program made no reference to it at all, and even if I explicitly told it not to. Anyone else had that problem? Any ideas on how to prevent it? I have the same vestigial inclusion of tkinter (along with a dozen other unwanted things), presumably drawn indirectly from some library I use. I haven't tried excluding it yet though, as I'm still working on getting it to work. What exactly is happening? Do you mean you put tkinter in the excludes option for py2exe, and it still showed up? -Jasper
Re: [pygame] Executable creation blues
On 9/27/06, Jasper [EMAIL PROTECTED] wrote: Pypack? Based on a non-robust premise, and thus doesn't work for me. What kind of use-case do you have? Maybe I could customize Pypack to fit your needs. -- Sami Hangaslammi
Re: [pygame] Executable creation blues
I found the newer versions of py2exe to be very easy to use, and the
latest version seems to have fixed problems I had when I tried it
before (stuff with packaging pyOpenGL). Some packages are very large
(notably wxPython) but I highly recommend it as the only practical
method of distribution on windows.
I hate running python with command line args, so I made the script set
the args, so I could just run the script by itself (double click, or
from eclipse, whatever) in the same directory as the entry point
script. Below is my template I start with - I capitalized stuff I
change- let me know if when modified, it doesn't work for you
---
from distutils.core import setup
import py2exe
import sys
data_file_list = [YOURDATA.EXT, FILEHERE.EXT]
sys.argv[1:] = [py2exe, -O0, -b, 1]
setup(
version = 0.1.0,
description = YOUR DESCRIPTION,
name = YOUR TITLE,
options={py2exe:{optimize:2}},
data_files=file_dir_list,
windows = [ENTRY_POINT.py]
)
On 9/26/06, Jasper [EMAIL PROTECTED] wrote:
I've been mucking around with creating executables so that I don't have
to ship python in order for people to play my game, and am having a
disheartening amount of trouble sorting out what should be a basic step.
which basic step is that?
Is there anything else worth trying? Am I stuck fiddling with py2exe,
or rolling my own solution?
You're not stuck fiddling with py2exe if you get it to work... don't
despair, there's a lot of good work there you can make use of, and I'm
sure it can work for you
if your problem is with a specifc module, you might find some help
with the issue here:
http://www.py2exe.org/index.cgi/WorkingWithVariousPackagesAndModules
I'm beginning to seriously consider shipping Python, half a dozen
libraries, and .pyc files as a possible improvement. :-/
well not to put a too blunt point on it... but that's exactly what py2exe does.
