[Pythonmac-SIG] python and py2app help
Hi, I was wondering if someone could help me with a problem I'm having bundling my python script (originally built with the 2.5 version of Python that ships with OS X 10.5) with py2app. I've basically run through all the online help I can find on how to make it work (several times) and nothing has worked out. First, I tried running py2app following the Tutorial here: http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html . I received this error message: Traceback (most recent call last): File "/usr/local/bin/py2applet", line 5, in from pkg_resources import load_entry_point File "/System/Library/Frameworks/Python.framework/Versions/2.5/ Extras/lib/python/pkg_resources.py", line 2607, in File "/System/Library/Frameworks/Python.framework/Versions/2.5/ Extras/lib/python/pkg_resources.py", line 565, in resolve pkg_resources.DistributionNotFound: macholib>=1.3 So I figured the macholib library wasn't installed, so after some looking around i found this tutorial: http://aralbalkan.com/1675 so I followed it to the letter and received an error message that py2app couldn't find the modulegraph package >= 0.7.3, but I know I had installed a higher version. So things got even more confusing (for me), because I went into the python.org website and downloaded the 2.7 version of MacPython (thinking that might help). As soon as I did that, my script would no longer run from the shell, as it could not find any of the modules I had installed. After calling sys.path, I could see that it wasn't searching the proper paths for any of my 2.5 frameworks. In fact, searching my computer, I couldn't find the 2.5 frameworks anywhere. So then I uninstalled macports, reinstalled the modules (wxPython, PIL, pyglet, and others), reinstalled macports, etc. etc. Unfortunately, pyglet installed itself somewhere odd (and I have no idea why) and I haven't figured out how to get the new version of python (2.7) to permanently add its new path to sys.path. I've tried sys.path.append, but that doesn't seem to be a permanent fix. The other modules (wx, PIL) seem to have installed fine. Moreover, running the 'which python' command used to get me /usr/bin/python and now returns '/Library/Frameworks/Python.framework/Versions/2.7/bin/python'. So it gets stranger (to me). Following the py2app tutorial stills nets me an error message about macholib. Manually creating the setup.py file and calling py2app from within the python interpreter (per Aral Balkan's guide) doesn't get me any error messages about py2app, and the app actually does get built. Except it doesn't run because when I click on it, I get an error message about not being able to import the pyglet module. Also, I use TextWrangler for writing my scripts, and whenever I execute the script from within TextWrangler (via the program itself or by Terminal via TextWrangler), the script works great! So clearly TextWrangler is calling a different version of python (likely the original version 2.5 from \usr\bin\python?) that actually has the modules I need, but I could never get py2app to work in version 2.5, and when I installed MacPython, it seems to have overwritten 2.5 because now I can only initiate 2.7 in the shell, which then gets me error messages about importing modules. So my computer (and myself) is very confused about what version of Python is actually installed and operating from the shell or from TextWrangler. Additionally, regardless of version, I've never been able to get py2app to actually function. I have no idea where my 2.5 frameworks went, but they are still there, clearly, because TextWrangler calls them. I don't know how to force Terminal to open the \usr\bin\python version of python instead of the new version. I'm very new to programming and working with python and modules, etc (less than a week). I've written a pretty nice GUI program for having less than a week of experience, and all I'm trying to do is bundle it into an app. So I've learned what I could by following tutorials and instructions online, but now I feel that I've installed so many things following these tutorials that it's sort of confusing the whole system. Is there a way to basically just revert on back to a clean install of python and starting over? Or can someone help me get py2app to actually work from version 2.7/get version 2.7 to find my pyglet module. I feel like if I can solve that one problem it may actually build OK, despite the rather large mess I seem to have made of installs. I'm also very confused as to why TextWrangler can operate my script, or open termina (again, likely using the \usr\bin\python versionl, which then operates my script, whereas manually running the script from Terminal via python script.py gets me error messages about importing modules. ___ Pythonmac-SIG maillist - Pythonmac-
Re: [Pythonmac-SIG] py2app testing modulegraph
Ronald Oussoren wrote: Ronald Oussoren wrote: modulegraph should be platform independent indeed -- it's used by bbfreeze: http://pypi.python.org/pypi/bbfreeze/0.96.5 Though I think he's forked it. But it might be good to get in touch and see if he's got patches to integrate. I really don't understand why people think it is a good idea to fork opensource packages unless the original author is completely unresponsive and/or moves the project in a different direction. Even then I'd let the original author know about that. Neither do I -- indeed I specifically recommended that he report back to this list, and maybe even share more code with Py2app, as he was interested in making bb-freeze Mac-compatible at one point. But if he was interested in working more collaboratively, he probably wouldn't have started a brand new python bundling project in the first place! Ronald Oussoren wrote: And they very helpfully even didn't bother to document what they changed, or which version they forked. That makes comparing the two unnecessarily hard, and hence I won't bother to do so. Darn -- what a pain! Have you tried asking him? He's been pretty responsive on his list. By the way -- he did post on this list at one point looking for volunteers to work on the Mac version of bb-freeze, and I don't think he got any takers. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] MacPorts+"make; make install": Etiquette and Sanitation
I've been using *nix variants long enough (OS X 10.6 right now) to be totally reliant on the command line, but not long enough that I've got my head around managing dependencies. As a beginner, I started using my system's built in version of python, and if I needed a package, I installed ports, and if it wasn't there, I went through MacPython and tried again, and if I needed something that didn't work on those platforms, I used easy_install, or pip or fink or compiled myself, or messed with my path or changed some flags and when none of that worked I installed a newer or older version of Python (2.4 or 2.5 or 2.6 or 2.7 or 3) and tried everything again. Needless to say, using anything with more than a single dependency has been a nightmare, with lots of unprincipled trial and error, and only precarious peace. Two days ago I removed all Pythons except MacPorts 2.6 and Apple's built-in 2.5. No more MacPython. Then I uninstalled, cleaned and reinstalled every Python 2.6 package. I cleaned up my $PATH and $PYTHONPATH, and the latter just uses /opt. Great. One system. Very nice. I did this all to get Some Random Package working (SRP for short, you can perhaps insert igraph, cairo, matplotlib, num/sci/i/py), but after all that, the SRP still didn't work. After a day of trying everything, I uninstalled SRP and py26-SRP from ports, downloaded the most recent source, compiled and installed both myself. And this particular SRP works now. There was a small celebration, but this approach has a downside. In particular, if I ever have a port that depends on the SRP, than I will have to reinstall the troublesome ports. I expect to have to deal with conflicts when this happens. This is already happening in my currently stalled attempts to get pycairo working again. These downsides became apparent when I continued on to try and get SRP2 (cairo) working. Lots of other libraries depend on it, so I can't just uninstall it. I'm in the middle of this, and looking at another day of hacking away. Right now I've deactivated the SRP2 and py26-SRP2 ports. I didn't favor deactivation to uninstallation because I fully understand the consequences of deactivation, but because MacPorts let me. This is a good example of the unprincipled approach. With SRP2 deactivated, have I accidentally broken its dependents? Are those dependents using the SRP2 I compiled instead of the deactivated one that ports intended them for? Will this lead to problems? Recognizing that these questions as a warning sign, I'm worried that I'm not working towards peace. I figured that before I do more the wrong way, I should just ask the people who know about the right way. There are so many little decisions involved in keeping a sanitary, easy-to-maintain ecosystem of libraries: *I figure that I will inevitably have to go to source every now and then. I need a way to gingerly navigate any potential conflicts with an existing port of the same library. How do I walk the line, getting a port's dependents to only use it, while getting my scripts to only use the self-compiled new version. Is that even what I want? I suspect that the answer to this and all my other questions is at http://guide.macports.org/, but too much of it was over my head. I don't speak that language yet. *When I have different versions of a library to choose from, I can select one during compilation with ./configure, I can prefer one in my .profile, or even keep multiple eggs in different locations and prefer one by extending python's sys.path in each script I write. Which of these is considered kludge and what are the best practices and rules of thumb. I realize that "it depends," a lot, but if any heuristics pop to mind, I'd be very grateful. *Since MacPort's python has trumps, every homemade egg now installs itself in opt (the crazy /opt/.../Python.framework/.../site-packages path). Is that unsanitary since it wasn't from ports? Am I setting myself up for headaches? These little things are exactly the little incremental procedural specs that pile up and eventually make everything go to hell. I'm not so interested in advice for this or that library, but an approach that will serve me well forever as a kludge-prone *NIX user who is tired of getting into trouble. Is there some article about managing libraries that I should have read years ago? Is this suffering simply a part of life? Are there best practices, or does everyone have their own special approach with its own special problems? Sorry this was so long-winded. Thank you for your help. Hopefully I'm not alone here. Best, seth. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] py2app not happy with zope.interface
In article <793a2d4f-e7f2-4285-9d8e-6c7588251...@mac.com>, Ronald Oussoren wrote: > On 21 Jul, 2010, at 22:24, Russell E. Owen wrote: > > > A py2app-built application stopped building properly recently after > > various upgrades. It would fail immediately on startup complaining that > > it could not find zope.interface. The app uses Twisted, which is why it > > needs zope.interface. > > > > I tried adding "zope" or "zope.interface" to "packages", but neither > > worked (in particular, the latter resulted in a traceback during the > > build). > > > > What did work was to add a blank __init__.py file to the "zope" > > directory in site-packages. But I don't know why that was useful. (I > > realize it makes zope into a package, but I don't know why that was > > necessary because zope.interface can already be imported from the > > command line -- presumably due to a pth file). > > How did you install zope.interface? Basically which easy_install or pip > command-line did you use to install? I used "pip install zope.interface". > I guess the nspkg.pth ensures that zope.interface can be imported without an > __init__ file and py2app doesn't parse those files (or doesn't understand how > to do so). If I can reproduce the problem I can (and will) fix it. That would be much appreciated (though the workaround is clearly not too bad). Regards, -- Russell ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] py2app not happy with zope.interface
I used "pip install zope.interface". -- Russell On Jul 22, 2010, at 7:05 AM, Ronald Oussoren wrote: On 21 Jul, 2010, at 22:24, Russell E. Owen wrote: A py2app-built application stopped building properly recently after various upgrades. It would fail immediately on startup complaining that it could not find zope.interface. The app uses Twisted, which is why it needs zope.interface. I tried adding "zope" or "zope.interface" to "packages", but neither worked (in particular, the latter resulted in a traceback during the build). What did work was to add a blank __init__.py file to the "zope" directory in site-packages. But I don't know why that was useful. (I realize it makes zope into a package, but I don't know why that was necessary because zope.interface can already be imported from the command line -- presumably due to a pth file). How did you install zope.interface? Basically which easy_install or pip command-line did you use to install? I guess the nspkg.pth ensures that zope.interface can be imported without an __init__ file and py2app doesn't parse those files (or doesn't understand how to do so). If I can reproduce the problem I can (and will) fix it. Ronald ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] OS 10.6 tkinter
After a bit of a struggle I managed to get PIL, reportlab and its extensions all built and surviving their tests. This is on Intel OS 10.6.2 with the original python 2.6.1. Now I want to make use of a simple Tkinter+Pmw application which is running fine under windows and linux, but segfaults on 10.6.2 First off what kind of debugging can I expect to accomplish with 10.6.2? Does it do core dumps etc etc? I have a giant textual dump of threads etc etc, but that doesn't seem immediately useful to me as a non-mac person . Interval Since Last Report: 34009 sec Crashes Since Last Report: 2 Per-App Interval Since Last Report: 154 sec Per-App Crashes Since Last Report: 2 Anonymous UUID: 05E43603-6DF7-49A2-87E8-BBF461A66996 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: 0x000d, 0x Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: objc_msgSend() selector name: release Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x7fff80645120 objc_msgSend + 44 1 com.apple.CoreFoundation0x7fff875b7246 _CFAutoreleasePoolPop + 230 2 com.apple.Foundation0x7fff80dcb2f8 -[NSAutoreleasePool drain] + 158 3 com.tcltk.tklibrary 0x0001012f7a4f XQueryPointer + 2425 4 com.tcltk.tklibrary 0x0001012f7d3f Tk_MacOSXSetupTkNotifier + 614 5 com.tcltk.tcllibrary0x0001011b52ae Tcl_DoOneEvent + 297 6 _tkinter.so 0x0001001f1be9 init_tkinter + 1132 7 org.python.python 0x0001000891df PyEval_EvalFrameEx + 15001 ... presumably this is some Tkinter/tk/tcl problem; any one have any ideas? -- Robin Becker ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] py2app testing modulegraph
On 22 Jul, 2010, at 15:11, Ronald Oussoren wrote: > > On 21 Jul, 2010, at 18:54, Christopher Barker wrote: > >> Ronald Oussoren wrote: >>> modulegraph should be platform independent >> >> indeed -- it's used by bbfreeze: >> >> http://pypi.python.org/pypi/bbfreeze/0.96.5 >> >> Though I think he's forked it. But it might be good to get in touch and see >> if he's got patches to integrate. > > I really don't understand why people think it is a good idea to fork > opensource packages unless the original author is completely unresponsive > and/or moves the project in a different direction. Even then I'd let the > original author know about that. And they very helpfully even didn't bother to document what they changed, or which version they forked. That makes comparing the two unnecessarily hard, and hence I won't bother to do so. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] py2app testing modulegraph
On 21 Jul, 2010, at 18:54, Christopher Barker wrote: > Ronald Oussoren wrote: >> modulegraph should be platform independent > > indeed -- it's used by bbfreeze: > > http://pypi.python.org/pypi/bbfreeze/0.96.5 > > Though I think he's forked it. But it might be good to get in touch and see > if he's got patches to integrate. I really don't understand why people think it is a good idea to fork opensource packages unless the original author is completely unresponsive and/or moves the project in a different direction. Even then I'd let the original author know about that. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] py2app not happy with zope.interface
On 21 Jul, 2010, at 22:24, Russell E. Owen wrote: > A py2app-built application stopped building properly recently after > various upgrades. It would fail immediately on startup complaining that > it could not find zope.interface. The app uses Twisted, which is why it > needs zope.interface. > > I tried adding "zope" or "zope.interface" to "packages", but neither > worked (in particular, the latter resulted in a traceback during the > build). > > What did work was to add a blank __init__.py file to the "zope" > directory in site-packages. But I don't know why that was useful. (I > realize it makes zope into a package, but I don't know why that was > necessary because zope.interface can already be imported from the > command line -- presumably due to a pth file). How did you install zope.interface? Basically which easy_install or pip command-line did you use to install? I guess the nspkg.pth ensures that zope.interface can be imported without an __init__ file and py2app doesn't parse those files (or doesn't understand how to do so). If I can reproduce the problem I can (and will) fix it. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
