Re: [Pythonmac-SIG] gmpy universal build (static)?
I like most do not like all that DarwinPorts and Fink bring in when you install them. So, I have been developing my own scripts as well. Currently, I use a model for the script based on the actions that DarwinPorts does when it installs packages, but using bash scripts rather than tcl which I never really liked. You may view some of them at http://idisk.mac.com/kranki-Public if you are interested. mkLibexpat.sh is my primary script where I develop new features and then push them back into the other scripts. I have not tried to make any of them universal installations nor have I added binary installs, currently just source installs. I own 7 macs of varying types and running these scripts has really not been much of a burden. Besides, I just didn't feel that I wanted them taking up twice as much harddrive space, but I am not opposed to adding that ability to them if needed. They were written by me and have not had any sort of review by others which I would like. So, even if you do not want to use them, but review them, I would appreciate the feedback. I am going to use them whether anyone else does or not until I find something better. Anyway, they are not copyrighted because they are not that important. However, I do believe that it is important to provide the build scripts being used to create the binaries that are being distributed and to distribute them with the binaries. They provide an educational benefit as well as a potential source of improvements if made available. I would be willing to provide some time to help in creating and maintaining them in collaboration with others. Just let me know. ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building 2.4
On Dec 2, 2004, at 12:50 PM, David Reed wrote: On Dec 2, 2004, at 10:11 AM, Bob Ippolito wrote: On Dec 2, 2004, at 10:00, Samuel M.Smith wrote: Would anyone care to post step by step instructions for building a framework version of Python 2.4 that will peacefully cohabitate with the built in OS X Python 2.3. Does it build out of the box from the source? Patch your config/Makefile of your existing Python 2.3.0 installation (see a recent email of mine on the subject) Fetch 2.4 sources From the 2.4 source directory do the following: env MACOSX_DEPLOYMENT_TARGET=10.3 ./configure --enable-framework make sudo make frameworkinstall You probably want to add /usr/local/bin early on in your path if you haven't already, you may want to delete /usr/local/bin/python if you want python 2.3 to be "the default", because there is also a symlink named python2.4 that you could use. Can anyone explain or point me to something to read about the benefits/trade-offs of using the framework version (I'm a long time Linux/Solaris user, but new to OS X) vs. just a regular compilation? It's supported by the people who know most about Python on Mac OS X, and it's the same type of install that Apple provides. Technically, the difference is mostly where the files go. It's a heck of a lot easier to move or remove a framework installation, or to naively embed Python into an application bundle. A normal install probably works too, but I have no need for one and thus haven't tested it in a long time. If you have problems with it, you're probably not going to get any help from me. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Question using cvs2svn
On Dec 2, 2004, at 16:58, Jack Jansen wrote: On 2-dec-04, at 18:19, Janice Cheung wrote: Greetings! I recently installed cvs2svn (a version of subversion) on my Mac OS X 10.3.6. I've also installed Sleepycat Berkeley DB 4.3.21. When I attempt to run $"cvs2svn" at the prompt, I receive this error message: ERROR: your installation of Python does not contain a suitable DBM module. This script cannot continue. to solve: see http://python.org/doc/current/lib/module-anydbm.html for details. That is indeed a rather stupid error message: what it tries to say is that the only Python dbm modules that are available are not good enough for cvs2svn. So you need to install one that is good enough (such as Sleepycat Berkeley DB), but you also need to install the corresponding Python module. Does anyone happen to know about an easy to install DB + Python module? Bob, anything in your PackMan database, maybe? The one in my PackMan database may be too old.. building bsddb3 from source is probably a good idea. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building 2.4
On Dec 3, 2004, at 10:55, Samuel M. Smith wrote: On Dec 2, 2004, at 08:11, Bob Ippolito wrote: On Dec 2, 2004, at 10:00, Samuel M.Smith wrote: Would anyone care to post step by step instructions for building a framework version of Python 2.4 that will peacefully cohabitate with the built in OS X Python 2.3. Does it build out of the box from the source? Patch your config/Makefile of your existing Python 2.3.0 installation (see a recent email of mine on the subject) Fetch 2.4 sources Is this the patch you mean? The correct linker settings are not adopted by any mainline version of Python 2.3. I had thought they were in 2.3.4, but they're not. Only Python 2.4 builds correctly by default. Also, Apple's build of Python 2.3.3 in the WWDC 2004 preview <http://www.opensource.apple.com/darwinsource/WWDC2004/python-11/> adopts a similar method to this patch, but slightly modified so that it does not depend on MACOSX_DEPLOYMENT_TARGET being set: (this is what a good /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/config/Makefile should look like, starting on or around line 98) LDSHARED= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) $(LDFLAGS) -bundle -undefined dynamic_lookup BLDSHARED= env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) $(LDFLAGS) -bundle -undefined dynamic_lookup Yes. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building 2.4
On Dec 3, 2004, at 10:55, Ronald Oussoren wrote: On 3-dec-04, at 15:23, Jack Jansen wrote: On 3 Dec 2004, at 10:56, Ronald Oussoren wrote: It would also be possible to monkey-patch the 2.3 install. IIRC I've posted one way to do a long time ago. That message should be in the archives. The advantage would be that you do not have to patch files in /System, we could even use this to install include files outside of /System while keeping them functional. The disadvantage is that my approach seems to induce vomitting in some people ;-) I assume that was me:-) Me too :-) But I can't for the life of me remember how you did it. Do you have a reference? I don't have a reference, but I do remember what I did: 1) Create a .pth file containing:: import sys; sys.path.insert(0, '/Library/Python/2.3/python-fixes') 2) In /Library/Python/2.3 create a distutils package with only a __init__.py. That __init__.py should extend/set the __path__, to make sure we can import the rest of distutils. It should then 'execfile' the real distutils.__init__ and finally patch up distutils. This is a gross hack, but is a relatively clean way to perform non-invasive surgery on an existing python installation. At least it doesn't requiry people to use the shell and sudo (both of which are scary for lots of peoply). I'll see if I can build a working example for this tomorrow. It would be easier to just build a .pkg installer that has a preflight script that checks for OS X 10.3.x, and does the patch. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building Numeric Python on Panther
On Dec 3, 2004, at 14:01, Bill Janssen wrote: I just downloaded the latest versions of numarray and Numeric Python. numarray builds and installs without problems, but Numeric fails -- it seems to have a bad setup.py file that references missing directories such as "/usr/include/atlas". Is there a set of patches for building this on Panther against the stock 2.3.0 Python release? http://mail.python.org/pipermail/pythonmac-sig/2004-November/012077.html (Bonus question: the Numeric Python documentation makes it clear that numarray should be used, but not how. Is numarray a substitute for all of Numeric? If not, should numarray be installed before NumPy?) I think what they mean is that new applications should use numarray. I think the Python API is largely the same, but not everything is the same (the C API, for example). There are no interdependencies, so installation order isn't going to make a lick of difference. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: [Pyobjc-dev] PyObjC py2app-branch merged to trunk
What version of Mac OS X is this? On Dec 4, 2004, at 10:36, Victor Ng wrote: I'm having problems with buliding the example applications - not really sure what I'm doing wrong. I've just installed py2app from it's svn trunk, and pyobjc from svn trunk. When I run setup.py py2app on the CurrencyConverter example, I get an error dialog popping up with: ImportError: '/Users/victorng/dev/pyobjc/trunk/pyobjc/Examples/CurrencyConverter/ dist/CurrencyConverter.app/Contents/Resources/Python/lib-dynload/objc/ _objc.so' not found When I try looking in the lib-dynload directory - I don't have any objc, AppKit or other directories that I think I'm supposed to be getting. Any pointers? vic On Sun, 28 Nov 2004 23:58:38 -0500, Bob Ippolito <[EMAIL PROTECTED]> wrote: The py2app-branch of PyObjC has been merged to trunk, and development will continue on trunk. For those of you that have checked out py2app-branch, please svn switch back to http://svn.red-bean.com/pyobjc/trunk/pyobjc Enhancements include but are not limited to: - All buildapp.py scripts are gone, bundlebuilder is no longer used anywhere. Examples now have setup.py scripts and are built with "python setup.py py2app". - The way setup.py works has changed significantly. It now supports a bdist_mpkg command to build a .mpkg distribution containing both PyObjC and py2app - Includes a copy of what will be py2app 0.1.6 (or possibly 0.2.0 .. depending on what else I change) - Enhanced compatibility with the Apple Objective C runtime - Bugfixes and minor feature additions on several other fronts - A sandbox directory with some new half-baked ideas for a new Objective C header parser The Xcode template still does not support py2app. I would recommend that if you use Xcode, you should only use it for development. Deployment should be done using py2app. -bob --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Pyobjc-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pyobjc-dev ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: [Pyobjc-dev] PyObjC py2app-branch merged to trunk
After waking up a bit I realized this is could possibly be because you didn't remove an old PyObjC installation first. Do that, and then reinstall. Using the bdist_mpkg installer (which will also install py2app) is another way to wipe the old installation clean. From the pyobjc source tree: % python setup.py bdist_mpkg --open If that doesn't work, I'm not sure what to tell you, because it works just fine on three computers here (one OS X 10.2 and two OS X 10.3) with standard-enough configurations. -bob On Dec 4, 2004, at 11:45, Bob Ippolito wrote: What version of Mac OS X is this? On Dec 4, 2004, at 10:36, Victor Ng wrote: I'm having problems with buliding the example applications - not really sure what I'm doing wrong. I've just installed py2app from it's svn trunk, and pyobjc from svn trunk. When I run setup.py py2app on the CurrencyConverter example, I get an error dialog popping up with: ImportError: '/Users/victorng/dev/pyobjc/trunk/pyobjc/Examples/CurrencyConverter/ dist/CurrencyConverter.app/Contents/Resources/Python/lib-dynload/ objc/_objc.so' not found When I try looking in the lib-dynload directory - I don't have any objc, AppKit or other directories that I think I'm supposed to be getting. Any pointers? vic On Sun, 28 Nov 2004 23:58:38 -0500, Bob Ippolito <[EMAIL PROTECTED]> wrote: The py2app-branch of PyObjC has been merged to trunk, and development will continue on trunk. For those of you that have checked out py2app-branch, please svn switch back to http://svn.red-bean.com/pyobjc/trunk/pyobjc Enhancements include but are not limited to: - All buildapp.py scripts are gone, bundlebuilder is no longer used anywhere. Examples now have setup.py scripts and are built with "python setup.py py2app". - The way setup.py works has changed significantly. It now supports a bdist_mpkg command to build a .mpkg distribution containing both PyObjC and py2app - Includes a copy of what will be py2app 0.1.6 (or possibly 0.2.0 .. depending on what else I change) - Enhanced compatibility with the Apple Objective C runtime - Bugfixes and minor feature additions on several other fronts - A sandbox directory with some new half-baked ideas for a new Objective C header parser The Xcode template still does not support py2app. I would recommend that if you use Xcode, you should only use it for development. Deployment should be done using py2app. -bob --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Pyobjc-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pyobjc-dev --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.http://productguide.itmanagersjournal.com/ ___ Pyobjc-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pyobjc-dev ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: [Pyobjc-dev] PyObjC py2app-branch merged to trunk
On Dec 5, 2004, at 10:29, Victor Ng wrote: Thanks for the tips - I'm on 10.3 and I've just gone through and deleted py2app and PyObjC files from /Library/Python/2.3/ and /System/Library/.../site-packages, reinstalled using the bdist pkg and still no luck. These are separate directories!@"?# site-packages should be a symlink to /Library/Python/2.3. Maybe wxPython broke your symlink? I just tried everything on another 10.3 machine and everything works without any issues. Weird. I've been getting other strange behavior on my computer - time to reinstall Panther. crap. Yeah. It does work fine on a normal setup :) -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building 2.4
On Dec 5, 2004, at 2:21 PM, Robert Valsjö wrote:
On 2004-12-02, at 16.11, Bob Ippolito wrote:
On Dec 2, 2004, at 10:00, Samuel M.Smith wrote:
Would anyone care to post step by step instructions for building a
framework version of Python 2.4
that will peacefully cohabitate with the built in OS X Python 2.3.
Does it build out of the box from the source?
Patch your config/Makefile of your existing Python 2.3.0 installation
(see a recent email of mine on the subject)
Fetch 2.4 sources
From the 2.4 source directory do the following:
env MACOSX_DEPLOYMENT_TARGET=10.3 ./configure --enable-framework
make
sudo make frameworkinstall
You probably want to add /usr/local/bin early on in your path if you
haven't already, you may want to delete /usr/local/bin/python if you
want python 2.3 to be "the default", because there is also a symlink
named python2.4 that you could use.
-bob
Hi!
When I do this I get:
esac
Traceback (most recent call last):
File "./setup.py", line 1061, in ?
class PyBuildInstallLib(install_lib):
File "./setup.py", line 1067, in PyBuildInstallLib
so_ext = sysconfig.get_config_var("SO")
File "/Users/robert/Desktop/Python-2.4/Lib/distutils/sysconfig.py",
line 509, in get_config_var
return get_config_vars().get(name)
File "/Users/robert/Desktop/Python-2.4/Lib/distutils/sysconfig.py",
line 486, in get_config_vars
func()
File "/Users/robert/Desktop/Python-2.4/Lib/distutils/sysconfig.py",
line 371, in _init_posix
raise DistutilsPlatformError(my_msg)
distutils.errors.DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET
mismatch: now "" but "10.3" during configure
make: *** [sharedmods] Error 1
Yes, also set the environment variables for make.
-bob
___
Pythonmac-SIG maillist - [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: Re[2]: [Pythonmac-SIG] Building 2.4
On Dec 6, 2004, at 4:52, Floris van Manen wrote: BI> Yes, also set the environment variables for make. Being a novice python programmer for at least some years to come, a simple question came up. How difficult would it be for the eminent mac python gurus to provide a python script (GetGoing.py :-) doing all the installation needed to install the new 2.4 version as a *replacement* for the pre-installed 2.3 version on osx 10.3 ? Extremely difficult, because nobody who knows what they're doing is going to encourage you to replace *ANY* pre-installed Apple software. Touching files in /System and /usr (except /usr/local) is primarily reserved for Apple, and changing anything in there is almost guaranteed to break something. Install it to the standard place, and change your $PATH such that /usr/local/bin comes before /usr/bin. Then when you type "python" you get Python 2.4. That's probably what you actually want, anyway. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building 2.4
On Dec 6, 2004, at 12:44 PM, whamoo wrote: Extremely difficult, because nobody who knows what they're doing is going to encourage you to replace *ANY* pre-installed Apple software. Touching files in /System and /usr (except /usr/local) is primarily reserved for Apple, and changing anything in there is almost guaranteed to break something. Install it to the standard place, and change your $PATH such that /usr/local/bin comes before /usr/bin. Then when you type "python" you get Python 2.4. That's probably what you actually want, anyway. But in this way i need to reinstall all third part modules There is a way to use old modules with python2.4 without reinstall all? (i have all modulen in (Library/Python/2.3) No! You must reinstall all third party modules that have compiled extensions. Python 2.3 and Python 2.4 DO NOT have binary compatible C APIs. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] [ANN] py2app 0.1.6
I've rolled together a new 0.1.6 release of py2app <http://undefined.org/python/#py2app> that includes the following feature enhancements and probably a few bug fixes: modulegraph: - This is now a top-level package and should be cross-platformish and not at all py2app specific (if someone wants a project, integrate this into py2exe/cx_Freeze/etc.) altgraph: - Some common code between modulegraph and macholib was moved into altgraph (the ObjectGraph data structure, for example) macholib: - Lots of code in its supporting library, ptypes, was removed, rewritten and optimized for performance and simplicity. - The API has totally been changed (I don't think anyone else uses it, so I don't feel bad about it :) - It uses altgraph for its data structure now - More correct algorithms for locating dylibs and frameworks based upon a thorough reading of the dyld source code bdist_mpkg: - Made the dependency checking more specific for better Installer compatibility - Fixed some minor bugs py2app: - New "plugin" target for building loadable bundles (i.e. Interface Builder palettes). This is a crazy hack, and will never work perfectly due to the icky globalness of the Python interpreter, but works well enough in practice. - Plugin example - Sets a new ARGVZERO environment variable that points to the argv[0] that was passed to main(...). - Sets a new EXECUTABLEPATH environment variable that points to the actual path of the executable that was run (which will be == to ARGVZERO most of the time) - suboptimal PyQt support (sip and PyQt are built in really strange ways and have lots of interdependencies at the C/C++ level so whenever you use ANY sip module you use ALL sip modules) - PyQt example - suboptimal PyOpenGL support (PyOpenGL has a stupid way of finding its version that prevents it from being easily bundled) - PyOpenGL example - py2applet command line tool (performs the same function as the GUI app) -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: [Pyobjc-dev] [ANN] py2app 0.1.6
I did some reorganization of the packages (I put them in a .pth'ed directory). It does clean out some of the old py2app, but fails to clean out macholib and altgraph. If you do this, then it should work, because the "py2app" directory was indeed cleaned when you upgraded: rm -rf /Library/Python/2.3/macholib rm -rf /Library/Python/2.3/altgraph Typically bdist_mpkg installers *do* clean their target first, but in this case, it's installing to a different location entirely (py2app/macholib, py2app/altgraph, etc..), so the old targets were not removed. I didn't bother to test the upgrade scenario when cutting the release, so I didn't think to add these additional steps in the preflight script. Future upgrades won't have this problem, as I don't see a need to move things around like this again anytime soon :) -bob On Dec 7, 2004, at 4:00 AM, Kaweh Kazemi wrote: bob, i've installed py2app-0.1.6.mpkg (i had previously 0.1.5 installed, which i didn't de-install, presuming that this will be done automatically). that's what i get: Traceback (most recent call last): File "setup.py", line 6, in ? import py2app File "/purelib/py2app/py2app/__init__.py", line 33, in ? File "/purelib/py2app/py2app/install.py", line 15, in ? File "/purelib/py2app/py2app/command/__init__.py", line 1, in ? File "/purelib/py2app/py2app/build_app.py", line 20, in ? File "/purelib/py2app/modulegraph/find_modules.py", line 21, in ? File "/purelib/py2app/modulegraph/modulegraph.py", line 15, in ? ImportError: No module named ObjectGraph did i miss anything? thanks, kw. On 07.12.2004, at 06:49, Bob Ippolito wrote: I've rolled together a new 0.1.6 release of py2app <http://undefined.org/python/#py2app> that includes the following feature enhancements and probably a few bug fixes: modulegraph: - This is now a top-level package and should be cross-platformish and not at all py2app specific (if someone wants a project, integrate this into py2exe/cx_Freeze/etc.) altgraph: - Some common code between modulegraph and macholib was moved into altgraph (the ObjectGraph data structure, for example) macholib: - Lots of code in its supporting library, ptypes, was removed, rewritten and optimized for performance and simplicity. - The API has totally been changed (I don't think anyone else uses it, so I don't feel bad about it :) - It uses altgraph for its data structure now - More correct algorithms for locating dylibs and frameworks based upon a thorough reading of the dyld source code bdist_mpkg: - Made the dependency checking more specific for better Installer compatibility - Fixed some minor bugs py2app: - New "plugin" target for building loadable bundles (i.e. Interface Builder palettes). This is a crazy hack, and will never work perfectly due to the icky globalness of the Python interpreter, but works well enough in practice. - Plugin example - Sets a new ARGVZERO environment variable that points to the argv[0] that was passed to main(...). - Sets a new EXECUTABLEPATH environment variable that points to the actual path of the executable that was run (which will be == to ARGVZERO most of the time) - suboptimal PyQt support (sip and PyQt are built in really strange ways and have lots of interdependencies at the C/C++ level so whenever you use ANY sip module you use ALL sip modules) - PyQt example - suboptimal PyOpenGL support (PyOpenGL has a stupid way of finding its version that prevents it from being easily bundled) - PyOpenGL example - py2applet command line tool (performs the same function as the GUI app) -bob --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Pyobjc-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pyobjc-dev ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: [Pyobjc-dev] [ANN] py2app 0.1.6
er.. missed one: rm -rf /Library/Python/2.3/bdist_mpkg On Dec 7, 2004, at 4:18 AM, Bob Ippolito wrote: I did some reorganization of the packages (I put them in a .pth'ed directory). It does clean out some of the old py2app, but fails to clean out macholib and altgraph. If you do this, then it should work, because the "py2app" directory was indeed cleaned when you upgraded: rm -rf /Library/Python/2.3/macholib rm -rf /Library/Python/2.3/altgraph Typically bdist_mpkg installers *do* clean their target first, but in this case, it's installing to a different location entirely (py2app/macholib, py2app/altgraph, etc..), so the old targets were not removed. I didn't bother to test the upgrade scenario when cutting the release, so I didn't think to add these additional steps in the preflight script. Future upgrades won't have this problem, as I don't see a need to move things around like this again anytime soon :) -bob On Dec 7, 2004, at 4:00 AM, Kaweh Kazemi wrote: bob, i've installed py2app-0.1.6.mpkg (i had previously 0.1.5 installed, which i didn't de-install, presuming that this will be done automatically). that's what i get: Traceback (most recent call last): File "setup.py", line 6, in ? import py2app File "/purelib/py2app/py2app/__init__.py", line 33, in ? File "/purelib/py2app/py2app/install.py", line 15, in ? File "/purelib/py2app/py2app/command/__init__.py", line 1, in ? File "/purelib/py2app/py2app/build_app.py", line 20, in ? File "/purelib/py2app/modulegraph/find_modules.py", line 21, in ? File "/purelib/py2app/modulegraph/modulegraph.py", line 15, in ? ImportError: No module named ObjectGraph did i miss anything? thanks, kw. On 07.12.2004, at 06:49, Bob Ippolito wrote: I've rolled together a new 0.1.6 release of py2app <http://undefined.org/python/#py2app> that includes the following feature enhancements and probably a few bug fixes: modulegraph: - This is now a top-level package and should be cross-platformish and not at all py2app specific (if someone wants a project, integrate this into py2exe/cx_Freeze/etc.) altgraph: - Some common code between modulegraph and macholib was moved into altgraph (the ObjectGraph data structure, for example) macholib: - Lots of code in its supporting library, ptypes, was removed, rewritten and optimized for performance and simplicity. - The API has totally been changed (I don't think anyone else uses it, so I don't feel bad about it :) - It uses altgraph for its data structure now - More correct algorithms for locating dylibs and frameworks based upon a thorough reading of the dyld source code bdist_mpkg: - Made the dependency checking more specific for better Installer compatibility - Fixed some minor bugs py2app: - New "plugin" target for building loadable bundles (i.e. Interface Builder palettes). This is a crazy hack, and will never work perfectly due to the icky globalness of the Python interpreter, but works well enough in practice. - Plugin example - Sets a new ARGVZERO environment variable that points to the argv[0] that was passed to main(...). - Sets a new EXECUTABLEPATH environment variable that points to the actual path of the executable that was run (which will be == to ARGVZERO most of the time) - suboptimal PyQt support (sip and PyQt are built in really strange ways and have lots of interdependencies at the C/C++ level so whenever you use ANY sip module you use ALL sip modules) - PyQt example - suboptimal PyOpenGL support (PyOpenGL has a stupid way of finding its version that prevents it from being easily bundled) - PyOpenGL example - py2applet command line tool (performs the same function as the GUI app) -bob --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Pyobjc-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pyobjc-dev --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Pyobjc-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pyobjc-dev ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Won't Install Numarray-1.1.1 or Numeric_23.6
On Dec 7, 2004, at 11:57, Benjamin Abécassis wrote: Hi everyone, I can't install Numarray-1.1.1 or Numeric_23.6 After typing, python setup.py install it tells, error: command 'gcc' failed with exit status 1 Here is the complete log : running install running build running build_py running build_ext building '_numpy' extension gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/System/Library/Frameworks/vecLib.framework/Headers -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ python2.3 -c Src/arrayobject.c -o build/temp.darwin-7.6.0-Power_Macintosh-2.3/Src/arrayobject.o unable to execute gcc: No such file or directory error: command 'gcc' failed with exit status 1 If anyone is aware of that problem ??!! Apart from that python seems to mork pretty well... You're going to need to install Xcode. A default installation of Mac OS X does not have a C compiler. You could get a binary installer for Numeric 23.6 from here in the meantime, though: http://mail.python.org/pipermail/pythonmac-sig/2004-November/012077.html -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4
On Dec 8, 2004, at 1:53 PM, Christian Meesters wrote: On Dec 8, 2004, at 1:06 AM, Robert Valsjö wrote: How to upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 ... Thanks, interesting. But does anybody know how this will effect pythonw (e.g. for use with wxPython)? Admittingly I'm a bit hesitant to try out. The title is incorrect, it doesn't upgrade anything. It installs a new Python that is entirely separate from the existing installation. /usr/local/bin/python is Python 2.4.0 /usr/bin/python is Python 2.3.0 /usr/local/bin/pythonw is Python 2.4.0 /usr/bin/pythonw is Python 2.3.0 The only "upgrade" is the change to the PATH environment variable, which prioritizes /usr/local/bin over anything else when looking for what to execute if a full path isn't specified. Your wxPython for Python 2.3.0 is still there, and will be available from /usr/bin/pythonw. Of course, it won't be available from Python 2.4.0 unless you compile and install such a version of wxPython. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4
On Dec 8, 2004, at 2:13 PM, Christian Meesters wrote: On Dec 8, 2004, at 11:04 AM, Bob Ippolito wrote: On Dec 8, 2004, at 1:53 PM, Christian Meesters wrote: On Dec 8, 2004, at 1:06 AM, Robert Valsjö wrote: How to upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 ... Thanks, interesting. But does anybody know how this will effect pythonw (e.g. for use with wxPython)? Admittingly I'm a bit hesitant to try out. The title is incorrect, it doesn't upgrade anything. It installs a new Python that is entirely separate from the existing installation. /usr/local/bin/python is Python 2.4.0 /usr/bin/python is Python 2.3.0 /usr/local/bin/pythonw is Python 2.4.0 /usr/bin/pythonw is Python 2.3.0 Sure, I realised that we are dealing here with a fresh installation, but wasn't aware that this will include the pythonw framework. I guess your explicit statement is enough for people like me to understand ;-). I'll try it out this afternoon. pythonw is a shell script that has always shipped with framework builds of Python 2.3.0 and later, just like a pythonw.exe has shipped with the Windows version of Python for quite some time. There's nothing special about it. The fact that it happens to use a "fake" application bundle that lives in the deep dark depths of Python.framework is really just an implementation detail. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4
On Dec 8, 2004, at 8:52 PM, Christian Meesters wrote: Well, I followed Robert's instructions and it failed. I then tried to install 'directly' and got the same error message. Guess I must admit that I simply have no clue how to solve this problem. typing 'make' results in this: building 'waste' extension gcc -bundle -undefined dynamic_lookup build/temp.darwin-7.6.0-Power_Macintosh-2.4/wastemodule.o build/temp.darwin-7.6.0-Power_Macintosh-2.4/WEObjectHandlers.o build/temp.darwin-7.6.0-Power_Macintosh-2.4/WETabHooks.o build/temp.darwin-7.6.0-Power_Macintosh-2.4/WETabs.o -L../waste/Static Libraries -L/usr/local/lib -lWASTE -o build/lib.darwin-7.6.0-Power_Macintosh-2.4/waste.so -framework Carbon ld: table of contents for archive: ../waste/Static Libraries/libWASTE.a is out of date; rerun ranlib(1) (can't load from it) running build_scripts Can anybody give me a hint on what to do here? Yeah, do what it says: ranlib ../waste/Static\ Libraries/libWASTE.a -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Numarray 1.1 and Numeric 23.6
Darwinports isn't going to do anything for you without Xcode installed either! :) On Dec 8, 2004, at 11:08 PM, john lichtenstein wrote: Due to a combination of bad luck (dropping laptop onto stone) and good luck (new job) I just got a clean machine. I installed in order X11 and XCode from Apple, Fink, and Darinports. Then I used Darwinports to update Python, Numeric, and Numarray. In this was it required very little skill to set to [Python, numarray, Numeric] = [2.4, 1.1, 23.6]. From: Benjamin Abécassis <[EMAIL PROTECTED]> Date: December 7, 2004 8:57:48 AM PST To: [EMAIL PROTECTED] Subject: [Pythonmac-SIG] Won't Install Numarray-1.1.1 or Numeric_23.6 Hi everyone, I can't install Numarray-1.1.1 or Numeric_23.6 After typing, python setup.py install it tells, error: command 'gcc' failed with exit status 1 Here is the complete log : running install running build running build_py running build_ext building '_numpy' extension gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/System/Library/Frameworks/vecLib.framework/Headers -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c Src/arrayobject.c -o build/temp.darwin-7.6.0-Power_Macintosh-2.3/Src/arrayobject.o unable to execute gcc: No such file or directory error: command 'gcc' failed with exit status 1 If anyone is aware of that problem ??!! Apart from that python seems to mork pretty well... Thanks in advance. B.A. ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Proposed Mac OS X change for 2.3.5 and 2.4.1 - MACOSX_DEPLOYMENT_TARGET vs. Python, round two, fight!
I've included a lot of background information here, if you just want to know the details of the proposed change, skip to the bottom. As some of you may know, Python 2.4's configure script and distutils has some tricky behavior with regard to the ``MACOSX_DEPLOYMENT_TARGET`` environment variable on Mac OS X 10.3 and later. Unless otherwise specified, assume that I am talking about a build environment of Mac OS X 10.3 or later. This behavior is as follows: If ``MACOSX_DEPLOYMENT_TARGET`` is not set during configure: 1. distutils builds modules with ``-F/Python/Installation/Location -framework Python`` as per usual 2.3.x behavior if it is also not set 2. If ``MACOSX_DEPLOYMENT_TARGET`` is set during a later run of distutils, then distutils complains that "10.3" mismatches the configure time setting of "" This Python framework has the following misfeatures: 1. All your extensions are dependent on the installation location of this particular Python 2. This installation of Python 2.4 *may break the building of extensions* for any previous version of Python that uses the same distutils behavior. It will certainly break them if they are installed to the same framework directory, but if the version of Python 2.3 is early enough, such as the stock 2.3.0, it will break that too. Also, any future version of Python installed to the same frameworks directory *will break the building of extensions* for this Python installation! 3. The Python framework will not be compatible with versions of Mac OS X earlier than 10.3 anyway due to changes in libSystem! This is stupid, and it should NOT be default behavior! If ``MACOSX_DEPLOYMENT_TARGET`` is set to "10.3" or higher during configure: 1. distutils builds modules with ``-undefined dynamic_lookup`` 2. If ``MACOSX_DEPLOYMENT_TARGET`` is set to something other than "10.3", or unset, it will complain that the current setting mismatches the configure setting of "10.3" The features: 1. All your extensions are independent of the Python installation location, and are thus compatible with any other Python with the same major version. 2. This installation of Python 2.4 will still, unavoidably, break the building of extensions for any previous version of Python using the bad distutils behavior mentioned above. This installation is not susceptible to breakage, however. The misfeatures: 1. You need to have ``MACOSX_DEPLOYMENT_TARGET`` set during configure, most people don't know to do this. 2. You also need to have ``MACOSX_DEPLOYMENT_TARGET`` set when using distutils. Even less people know to do this. The solution to this is to have the following behavior instead: 1. If no ``MACOSX_DEPLOYMENT_TARGET`` is set during configure, and the build machine is Mac OS X 10.3 or later, then set it to "10.3". 2. If no ``MACOSX_DEPLOYMENT_TARGET`` is set during distutils, but it WAS set during configure, then set it to the configure time value. 3. Otherwise, if it is set to a LOWER value, then fail. Checking for an exact match is bad, because the user or extension author should be free to build a particular extension using 10.4 specific features against a Python that is 10.3+ compatible. For a build machine running Mac OS X 10.2 or earlier, it should ignore all of this behavior as per usual. Unless anyone has a reasonable objection to this proposed solution, then we should make sure it goes into Python 2.4.1 and Python 2.3.5. These threads might also be of interest: http://mail.python.org/pipermail/pythonmac-sig/2004-November/012192.html http://mail.python.org/pipermail/pythonmac-sig/2004-December/012237.html http://mail.python.org/pipermail/pythonmac-sig/2004-December/012275.html -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Re: How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4
On Dec 10, 2004, at 2:17 AM, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Subject:Re: Pythonmac-SIG Digest, Vol 20, Issue 11 Date: December 10, 2004 1:08:54 CST To: [EMAIL PROTECTED] Ran into some troubles with the below. Comments interspersed. From: Robert Valsjö <[EMAIL PROTECTED]> Date: December 8, 2004 3:06:50 CST To: [EMAIL PROTECTED] Cc: Subject: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 How to upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 >make >make frameworkinstall make frameworkinstall pbxcp: error: open(): ///Applications/MacPython-2.4/PythonLauncher.app/Contents/Info.plist: Permission denied ...failed PBXCp ///Applications/MacPython-2.4/PythonLauncher.app/Contents/Info.plist ... ** BUILD FAILED ** make[1]: *** [install_PythonLauncher] Error 1 make: *** [frameworkinstallapps] Error 2 Fine: I did sudo make frameworkinstall, which executes without error. >make frameworkinstallextras Same privileges complaint; same solution. Everything in the /Applications folder should be writable by anyone in the admin group, so your configuration is to blame here, not the instructions. Some package you installed probably had bad permissions... This should work for most systems. If you open up Disk Utility, there is a button that will repair permissions on a volume. With correct permissions, these steps should've succeeded. Given this error, you should probably do it. Change you PATH: >emacs ~/.bashrc Add: PATH=/usr/local/bin:$PATH export PATH OK. Then I do: python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> You also need to set the PATH from the shell prompt, or start a new terminal window. Editing .bashrc doesn't do anything to a currently running bash process. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4
On Dec 10, 2004, at 11:59, [EMAIL PROTECTED] wrote: From: Bob Ippolito <[EMAIL PROTECTED]> Date: December 10, 2004 1:29:53 CST To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Pythonmac-SIG] Re: How-To upgrade Apples python installation in Mac OS X 10.3 from python 2.3 to 2.4 >make >make frameworkinstall make frameworkinstall pbxcp: error: open(): ///Applications/MacPython-2.4/PythonLauncher.app/Contents/ Info.plist: Permission denied ...failed PBXCp ///Applications/MacPython-2.4/PythonLauncher.app/Contents/Info.plist ... ** BUILD FAILED ** make[1]: *** [install_PythonLauncher] Error 1 make: *** [frameworkinstallapps] Error 2 Fine: I did sudo make frameworkinstall, which executes without error. >make frameworkinstallextras Same privileges complaint; same solution. Everything in the /Applications folder should be writable by anyone in the admin group, so your configuration is to blame here, not the instructions. Some package you installed probably had bad permissions... This should work for most systems. If you open up Disk Utility, there is a button that will repair permissions on a volume. With correct permissions, these steps should've succeeded. Given this error, you should probably do it. I know this is somewhat off-topic, but I ran repair permissions using Disk Utility, and then manually went in and did chmod on both Contents and Info.plist so that both owner (root) and group (wheel) could rwx and rw the folder and file, respectively. I still get the permission error shown above. Weird, huh? Not really, Disk Utility is only responsible for repairing permissions that it knows about, namely, stuff it finds in package receipts. Since you installed this via make, and not Apple's Installer, it comes as no surprise that these files still have root permissions after a repair. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] PyCon 2005
On Dec 10, 2004, at 6:23 PM, Jacob Kaplan-Moss wrote: I'm thinking of proposing a talk at PyCon 2005 about MacPython, and I'd like to run my idea by the list: As I see it, there are three killer features in MacPython that you can't get anywhere else: PyObjC, CoreGraphics, and scripting with appscript. Given that 30 or 45 minutes won't be nearly enough to talk about all three, I'm thinking of focusing on the general topic of "scripting OS X" using appscript and CoreGraphics (AFAIK there's been a number of "Intro to PyObjC" talks given in the past, and I don't really want to reinvent the wheel). If there's anyone else proposing a talk at PyCon, I'd like to avoid stepping on any toes (as far as I'm concerned, the more MacPython talks the better), so if this overlaps/competes with your cool idea, please let me know. I did the "60 Minutes of MacPython" talk at PyCon 2004. I was initially thinking about doing another one this year, but I'm leaning towards doing a talk on just PyObjC. So, it would be awesome if you did a talk on CoreGraphics and appscript. That would leave me to talk about what I know best and am most interested in :) My slides, proposal, slide-creation-scripts, and notes taken during my presentation by the audience last year are available here: http://svn.red-bean.com/bob/pycon/2004/trunk/ I will likely break my PyObjC talk it into two separate 30 minute sessions: "intro to PyObjC" and "hacking with PyObjC". The first of which would be more like a tutorial and go over the obvious rapid development facilities that you have available such as Cocoa Bindings, using WebKit, table views, writing py2app scripts, using the Xcode template, using Renaissance instead of Interface Builder, what people are doing with PyObjC, etc. The second would go into writing plugins for existing applications, hacking existing classes with categories, injecting Python into arbitrary pids using pyject (a wrapper bbum and I wrote around mach_inject), wrapping near-arbitrary not-ObjC functions with loadBundleFunctions (a la ctypes), and possibly talk a little about the gritty implementation details of PyObjC if there's time/interest. If you have any questions or would like to collaborate a bit on our proposals/slides/scripts then feel free to contact me on or off list. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Won't Install Numarray-1.1.1 or Numeric_23.6 + Scipy
On Dec 15, 2004, at 12:01, Enrico Franchi wrote: On 15/dic/04, at 15:03, Benjamin Abécassis wrote: yes i've installed both, it now says (after reboot) : x11_info: FOUND: libraries = ['X11'] library_dirs = ['/usr/X11R6/lib'] include_dirs = ['/usr/X11R6/include'] Good. Fatal Python error: Interpreter not initialized (version mismatch?) I suppose you have installed two different python versions. For example I had this problem when I tried to install QT having both 2.4 and 2.3 installed. I had some misconfigurations, and while installing for 2.4 was straightforward, 2.3 gave me problems. This should be easily fixable. Anyway, which versions did you install (or am I totally wrong)? If you have a framework Python 2.4 installed, then you have broken extension building for any unpatched Python 2.3 installation. Please search the archives for more posts by me on this issue. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
On Dec 16, 2004, at 2:14 PM, has wrote: Bob wrote: [py2app] still does the dependency scan for third party python code and dependent libraries/frameworks. If you want to depend on third party stuff in site-packages, too bad, you'll have to exclude them all individually and use --site-packages. Why? Because I don't care about your use case. It's rare and is very often not what people want. If you're distributing an application with some particular package, like appscript, then just explicitly exclude appscript and turn on --site-packages and it will effectively be "without dependencies". -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
On Dec 16, 2004, at 2:35 PM, Chris Barker wrote: Bob Ippolito wrote: The way to tell it to include nothing is to build an alias bundle (-A), which is for development only and doesn't create something suitable for redistribution. Can you tell us more about what an Alias bundle is? Is like the old MacPython applet? What I would like is a bundle that includes all the code that isn't installed in the Python tree, but none of the code that is installed in that tree. Is that what an Alias bundle is? --semi-standalone includes all third party code (anything used by /Library/Python/2.3 and otherwise) and nothing else. This is the forced default if you are using a /System installation of Python. If you are using a third party Python, it is not the default. an alias bundle is for development, like bundlebuilder's --link option. It makes symlinks to any data files, and runs your code in-place. It's very very fast to build an alias bundle, and provides for a very fast edit/run cycle. The PyObjC documentation and tutorials have been updated to use py2app, you might want to also read this: http://svn.red-bean.com/pyobjc/trunk/pyobjc/Doc/tutorial/tutorial.html -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
On Dec 16, 2004, at 2:40 PM, has wrote: Bob wrote: [py2app] still does the dependency scan for third party python code and dependent libraries/frameworks. If you want to depend on third party stuff in site-packages, too bad, you'll have to exclude them all individually and use --site-packages. Why? Because I don't care about your use case. It's rare and is very often not what people want. How rare? Rare enough that I can't justify writing the code and adding yet another option. If you don't need a redistributable application, then use an alias bundle. If you want a redistributable application, then include the dependencies. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
On Dec 16, 2004, at 3:07 PM, Chris Barker wrote: Bob Ippolito wrote: Rare enough that I can't justify writing the code and adding yet another option. That, of course, is your judgment. However, I'm not sure it's a rare as you think. I, for one, want to be able to distribute apps to folks whose environment I have control over, so I know that they will have all the packages installed that my apps need, so I want them to just get the app-specific code. If you want to write and maintain that functionality, patches accepted. I haven't had a chance to try it yet, but it sounds like py2app does have a way to exclude specified packages, so I could just make a point of excluding wxPython, Numeric, PIL, MyPersonalPackage, etc, and I'd get what I want. Is that the case? Yes, the --excludes option does exactly that. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
On Dec 17, 2004, at 3:59 PM, Chris Barker wrote: I originally came down on Has' side of this debate, but now think Bob has made the right choices, so I thought I'd add a couple comments. First, I'm a little unclear on what exactly Has wants. Could you clarify? I think he just wants full control and is either not satisfied with the performance or modulegraph or doesn't trust it to do the right thing. Which is fine, but I don't really care. I'm more concerned about doing the right thing the majority of the time than accommodating strange requests. I have ideas about a refactoring at *some point* that would suit his use case, but it's still in the don't-really-need-it phase so it's not going to happen any time soon. Essentially, I may abstract the dependency analysis to plugins. Currently there are two mostly-but-not-really independent dependency analysis tools in py2app: macholib and modulegraph, which analyze Mach-O object files and Python bytecode respectively (the interdependency is introduced by py2app, not either of these packages, and that's because Python extensions are Mach-O object files). In "py2app 3000" the whole idea of dependency analysis will be abstract which would allow for cached dependency graphs or static dependency lists, analyzing code from other languages and architectures (Perl, Java, TCL, ELF, and other forms of brain damage I'm sure). But, again, this is a don't-really-need-it feature, so I may-not-actually-ever-implement-it. I imagine what is actually happening for him is that he is writing lots of little single-script applications that depend on some combination of his packages (appscript, aem, etc.), and for some reason, adding --site-packages --semi-standalone --excludes=appscript,aem,osaterminology,osax,LaunchServices (via commandline or options=dict(py2app=dict(...))) rubs him the wrong way. His problem with this method is probably only on a theoretical/philosophical level, since that invocation will effectively do exactly what he wants, but is not "optimal" because it does do a full dependency analysis of everything else it sees. Maybe his computer is really slow? I don't know. I know what I want, I think what Bob has done accomidates this very well. If you want an app that will run on the machine you developed it on, the Alias option is perfect. I wouldn't say that it's "perfect", but it does usually do the right thing in practice :) If you want to deploy an app to other users, but either know or expect them to have a bunch of stuff installed into their Python, you don't want it all included by Py2App. However, I realized that it is highly unlikely that your users will have the exact same installation as you do, so it's best to be explicte about what they need installed, and those things you specify to be excluded by Py2App. I, for instance, expect my users to have: wxPython PIL Numeric Installed, so I can exclude those, but I'd rather not inadvertantly create a dependence on an obscure package I forgot I had used. If you want to deliver some code with the idea that users are completely on their own about dependencies, then just deliver the code, and let them run Py2app themselves, if need be. So, the only use case I can think of for what Has is asking for is one where you want to deliver an app to users that are guaranteed to have EVERYTHING that the developer has installed. This does, indeed, sound like a rare use case to me. The largest reason I think Has' proposed option causes problems beyond what you've already mentioned is that is absolutely requires every single Python module and extension to be explicitly stated as an include. Currently you just point py2app at the main script and expect it to do the right thing (or at least something approaching that, depending on how crazy the code you're analyzing is). In the situation where dependency tracking is turned off, not only will you miss third party libraries and extensions that live on your sys.path, but you'll also miss modules and packages inside your application's source tree. py2app tries very hard, by default, to make the Python environment consistent regardless of what the end user has done to their system. This includes stomping on any PYTHONPATH and ignoring any site-packages that the user has. Due to this, the developer, on their development machine, can be reasonably certain that their application will run anywhere (for a reasonable expectation of anywhere) if it runs at all. So if modulegraph DID miss something, then the developer will know about it before he even tries running the application on another machine. Maybe I am doing a little too much forced-hand-holding and insulting the developer's intelligence a bit, but given the issues that I've seen with similar
Re: [Pythonmac-SIG] py2app standalone options
On Dec 16, 2004, at 6:29 PM, Bob Ippolito wrote: On Dec 16, 2004, at 6:00 PM, has wrote: On a separate issue, I've noticed the semi-standalone option appears to be buggy in 0.1.6. When I set it to true, py2app correctly omits standard modules and extensions from Resources/Python, but is still including the core Python.framework. I'm running MacPython 2.3.3 under OS 10.2.8. If you want the build logs and/or finished application bundles, let me know and I'll email them over. I'm pretty sure I know why this is, I'll fix it before next release. Fixed in r266. macholib detected Python as a non-system dependency when you end up using extensions not included in the standard library, since they are linked directly to the Python dylib (in some cases, but always for 10.2). Now py2app explicitly excludes any dylib that it thinks is Python when filtering dylibs in semi-standalone mode. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Won't Install Numarray-1.1.1 or Numeric_23.6 + Scipy
On Dec 15, 2004, at 1:20 PM, Robert Kern wrote: Benjamin Abécassis wrote: it works OK now, i just de-installed the first version, python works fine now (well just like before i installed Xcode, gcc etc... !!!) but i still have problems with scipy...it seems like the installer can not find a particular library, i've installed FFTW, F2PY though here is the log : [etc] Scipy also requires a FORTRAN compiler. If you have Fink, install the package g77. Otherwise, install g77 from http://hpc.sf.net . It's also called g77 in darwinports -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
On Dec 16, 2004, at 11:47 AM, has wrote: One for Bob really, but I'm trying to figure out how to build a non-standalone app using py2app. This was easy (albeit clumsy) with bundlebuilder - just set both 'standalone' and 'semi-standalone' options to False. I see a 'semi-standalone' option in py2app, but that still includes a big wadge of stuff I don't want/need, and I don't see any obvious, simple way to tell it not to include ANY external dependencies. Have I've missed something? (The current documentation is minimal, and the main docstring in particular appears out of date.) Or is it an oversight in the API/UI design, in which case I'd suggest replacing the boolean 'semi-standalone' option with a new 'dependencies' option that takes one of three values: 'all', 'semi', or 'none'. (py2app) --semi-standalone (-s) depend on an existing installation of Python 2.3 (FORCED: Using vendor Python) (bundlebuilder) --semi-standalone build a standalone application, which depends on an installed Python, yet includes all third-party modules. --semi-standalone means do not include a Python interpreter or anything from its standard library, and it means the same thing as it did in bundlebuilder. It still does the dependency scan for third party python code and dependent libraries/frameworks. If you want to depend on third party stuff in site-packages, too bad, you'll have to exclude them all individually and use --site-packages. The way to tell it to include nothing is to build an alias bundle (-A), which is for development only and doesn't create something suitable for redistribution. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
On Dec 16, 2004, at 6:00 PM, has wrote: Bob wrote: Because I don't care about your use case. It's rare and is very often not what people want. How rare? Rare enough that I can't justify writing the code and adding yet another option. If you don't need a redistributable application, then use an alias bundle. If you want a redistributable application, then include the dependencies. If you were writing py2app simply to please yourself I wouldn't bother raising the issue, but since you intend it to replace BundleBuilder in the standard distribution I can't really see "I don't care about your use case" being sufficient justification for such a design decision. You've just spent weeks, if not months, designing and constructing py2app - a not insignificant piece of software engineering. I'd be rather surprised if it'd take you more than a few minutes to insert an option that bypasses the modulegraph component at the point where it connects to the rest of py2app, assuming a properly-factored, maintainable design. As to what I want: I would like a really quick, easy way to churn out lightweight distributable applets that don't lug around stuff they don't need to. BundleBuilder has no problem doing this; heck, even a crap language like AppleScript can do it. Is it really py2app's place to dictate to users how they should or shouldn't build THEIR apps? Personally, if I want py2app to resolve and include my applications' dependencies, I shall be only too happy to ask it to do so. But if I don't, I'd appreciate it minding its own business respecting that choice. (And no, forcing me to manually resolve and manually exclude all my applications' dependencies for it doesn't count.) Adding this option causes more problems than it solves. I don't think it's a good idea and I don't want to support that usage, especially not at this time. py2exe does not implement this option either. I'm not going to implement this in py2app any time soon. Feel free to do it yourself, either by subclassing py2app (then using the cmdclass argument to setup(...)), or by writing a patch against py2app that makes this option available. On a separate issue, I've noticed the semi-standalone option appears to be buggy in 0.1.6. When I set it to true, py2app correctly omits standard modules and extensions from Resources/Python, but is still including the core Python.framework. I'm running MacPython 2.3.3 under OS 10.2.8. If you want the build logs and/or finished application bundles, let me know and I'll email them over. I'm pretty sure I know why this is, I'll fix it before next release. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 20, Issue 23
On Dec 19, 2004, at 12:37 PM, Jon Schull wrote: The problem of multiple pythons on OSX is really really crippling. I use visual python (which requires X which requires one python) and I want to work in and run with the standard OS X look and feel. I spend literally hours every month or two trying (unsuccessfully) to get the various systems to co-exist and the result is not pretty. At the moment, idle doesn't work anywhere, at all. Here's the tip of my iceberg. Suggestions welcome. 208-186-56-189:~ jis$ idle -bash: /sw/lib/python2.3/idlelib/idle.py: Permission denied 208-186-56-189:~ jis$ sudo idle Password: Traceback (most recent call last): File "/sw/bin/idle", line 3, in ? from idlelib.PyShell import main File "/sw/src/root-python23-2.3.4-2/sw/lib/python2.3/idlelib/PyShell.py", line 11, in ? File "/sw/lib/python2.3/threading.py", line 13, in ? from traceback import print_exc as _print_exc ImportError: cannot import name print_exc The ideal would of course be a single python. But failing that would be a single installer that would put in place the two (or even more) pythons needed in a manner that allowed one to work and install new modules as needed, without risking obscure disasters. There is definitely something wrong with your Fink installation of Python, which probably has no relevance to having multiple Python installations. I stay miles away from Fink, because terrible things have happened every time I've tried it, so I don't know what the problem is specifically. It's especially troubling to see that "idle" and "sudo idle" has different behavior. I suggest reporting these issues to the relevant maintainers for the Fink packages. That permission denied error looks like something is missing a +x and/or the "idle" shell script is not correct For what it's worth, I haven't had any such problems with Darwinports and its Python... however, VPython isn't available from Darwinports at this time, so it's probably not of much use to you yet. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 20, Issue 24
On Dec 20, 2004, at 8:30 AM, Jon Schull wrote: For what its worth I came across a seemingly related set of issues last night while trying to get apache to run python cgis. Our solution was to rewrite the #! lines as #! /sw/bin/env /sw/bin/python (the magic was in adding the first phrase). Related discusssion and alternative solutions is at http://projects.edgewall.com/trac/wiki/TracOnOsx Apache starts as root with root's default environment. It's not going to have /sw/bin in its path, so /usr/bin/env python is not going to run Fink python. You might as well replace it with #!/sw/bin/python. Why the hell does Fink have its own env, anyway? Jon said The ideal would of course be a single python. But failing that would be a single installer that would put in place the two (or even more) pythons needed in a manner that allowed one to work and install new modules as needed, without risking obscure disasters. Darwinports Python and the vendor Python play together perfectly nicely, with no obscure disasters anywhere that I've seen. If you are having conflicts between Fink and vendor Python, then it must be caused by Fink. Probably due to the init script in your .bashrc / .tcshrc that sets up your environment in such a way that everything you do can end up using or linking to Fink-built stuff. Darwinports doesn't have any such hacks, and never mangles your environment like that. Jack said This is a known problem, which is explained in Mac/OSX/Dist/README: Currently (November 2003) there is still a bug in the build procedure for $DESTROOT builds: building some of the applets will fail (in ``Mac/OSX/Makefile``) if you don't have the same version of Python installed normally. So before doing the distribution you should build and install a framework Python in the normal way. Unfortunately, the problem is rather difficult to fix. buildapplet (or py2app, or similar tools) will need to be told that we're in a destroot install situation, so that if it wants filenames it should use the non-destrooted version but if it actually needs the data that's in the files it should use the destrooted filename. I can live with the current workaround for MacPython installers, if it's a problem for darwinports file a bugreport and a solution may be available sooner:-) Jon sighs... Unfortunate indeed. You can live with it, and I don't even understand your explanation. ;-/ Its ironic that the python community values such elegance in the language yet tolerates such complexity in context. I presume that's because there's no alternative. As Jack said, if you do things in the supported way, it just works. DESTROOT is only used in relatively strange situations like when building packages with Darwinports (probably Fink too). Since Jack is the maintainer of Python, but not Fink or Darwinports Python, it's more or less YAGNI for him. Given extremely limited time and resources, why solve a problem you don't have? ... and the DESTROOT thing isn't really relevant to the problems you brought up, anyway. This particular limitation only matters if you are building a framework Python, and neither Fink nor Darwinports currently provide such a build. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 20, Issue 24
On Dec 21, 2004, at 7:22 AM, Brian Lenihan wrote: >> 208-186-56-189:/sw/bin jis$ cat /sw/bin/idle2.3 >> #!/sw/bin/python Which python is first on your path? IIRC there is a feature in darwin that wreaks havoc with the setup code in python that finds the correct prefix (and library). This ends up always picking the prefix for the first python on the path. Darwinports contains a patch for that. Using "#!/usr/bin/env /sw/bin/python" should also work. The "feature" is that OS X does not include the full path to the executable in argv[0]. Using #!/usr/bin/env /path/to/python helps. Especially in the really annoying case where command line scripts work, but scripts launched from applications don't. Which reminds me, both pyobjc's and py2app's bdist_mpkg also could be tweaked so preflight shell scripts won't fail to run on some systems: Actually, using #!/usr/bin/env %(sys.executable_path) *will* cause it to fail to run in more cases than it will not. I'll take your patch for adding a junk extension, but not this one. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Where to put data
On Dec 21, 2004, at 10:23 AM, Charles Hartman wrote: (I also posted this to wxusers because it's sort of cross-platform -- sorry if you're seeing it again.) With an earlier app I wanted an external data file and everybody told me to make it internal to the program (the app's Resources, I guess) instead. I couldn't, then. Now with a new app I want to do just that, but I'm not sure *how* to do it! It's a file of data -- a Python dictionary object, after it's loaded into memory -- which will grow and change as the app is used; when the app terminates the data ought to be saved with it for next time. In this case I don't want users fiddling with it apart from the app. What is the right way to do this? (What's the easy way?) Is there a simple method that will work for both Mac and Windows (and Linux)? The right way to do it is NOT to have this file inside your application. You should *never* assume that you can write to your own application bundle. You *should* have a way to create this file from scratch (which may be a template file inside Resources, which is never written to). As others have said there are different places you should put this file dependent on operating system.. On Mac OS X it should probably go in one of the "Application Support" directories. It's common convention to only place plist formatted files in the Preferences directory, so unless you're serializing this dictionary as a plist, I suggest going with Application Support instead of Preferences. On other *nix, it would typically go into a ~/.yourapplication directory. And for Windows, somewhere in their home directory (at least on NT-based Windows). Optionally, you could put it in the registry instead, which may be a good idea, depending on how big it is expected to get. As far as writing to your own application goes, here's a short list of why that's bad: - Will not work from CD-ROM, compressed disk image, etc. - Probably will not work multi-user - Probably a bad idea if the application is on a network drive - User may not have permissions to write to the application - If you break it, you really broke it. - It can look virus-like and be picked up as such (particularly on Win32 if you're writing to the .exe file). You should be able to trust the user not to fiddle with it apart from the app. Especially if it's a pickle file. It will be pretty buried, anyway. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Installing Twisted-1.3.0
On Dec 21, 2004, at 5:22 PM, Erik van Blokland wrote: this question might be more appropriate for a twisted forum. But before I throw myself to the wild animals, perhaps someone on this list has a clue for me. I'm attempting to install Twisted-1.3.0 on a G4 powerbook. I have installed the same version of twisted on a different G4 with OSX Server, and on another machine - plain OSX, all works fine. Now I want to include a 12" powerbook in the happy family, but it won't compile. As far as I can tell the pythons are all the same version, plain Apple 2.3. OSX 10.3.5. Python version: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Now then, installing Twisted-1.3.0 gives me this error. ~This is the shorter version, without all the copying. It's done that. [eBook:/code/Twisted-1.3.0] erik% sudo python setup.py build - building 'twisted.spread.cBanana' extension gcc -Wl,-F. -Wl,-F. -bundle -framework Python build/temp.darwin-7.7.0-Power_Macintosh-2.3/twisted/spread/cBanana.o -o build/lib.darwin-7.7.0-Power_Macintosh-2.3/twisted/spread/cBanana.so ld: can't locate file for: -lbundle1.o error: command 'gcc' failed with exit status 1 That is quite a strange error, but cBanana is not required nor even enabled by default these days. This is harmless. after that twisted imports in python, but not much else -- twisted.web fails. Just for luck I tried the upgrade to 10.3.7 didn't make any difference. What's much more important to see is *how* twisted.web fails. The cBanana stuff is totally harmless, though it sounds like Xcode might not be installed correctly if you're getting strange compile errors like that? Did you remember to python setup.py install? build won't install anything. FWIW, Twisted should run without ANY C extensions or ANY compilation. You can just point sys.path to /code/Twisted-1.3.0 and it will have a working twisted package. Also, the cfreactor in 1.3.0 is broken for PyObjC 1.1 and later, so maybe you should be trying Twisted 2.0-SVN instead.. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
On Dec 21, 2004, at 5:42 PM, has wrote: Chris Barker wrote: I originally came down on Has' side of this debate, but now think Bob has made the right choices, so I thought I'd add a couple comments. First, I'm a little unclear on what exactly Has wants. Could you clarify? Freedom, basically. It's easier to assemble a workflow by mixing and matching small, single-purpose components than to strip down a great big monolithic lump to get the pieces you want/need. If you're going to protect the end user from doing stupid things, that's great, but it should be done by the next layer up. Users who work at the top layer are protected; users who want/need to route around the 'dummy mode' restrictions can go in at the layer beneath. After all, it's the user's foot, and if they want to shoot holes in it in full knowledge of what they're doing then far be it for anyone or anything else to stand in their way. For example, appscript currently takes this approach. The lower-level aem package provides a comprehensive wrapper around the AEM; appscript builds on this to provide a nice, safe, friendly-looking user interface for application scripting. Most folks'll just use appscript for all their application scripting, but geeks who need access to the full AEM, e.g. to send asynchronous events, can use aem. Prior to 0.6.0 appscript was a monolithic system, which meant you were SOOL if you wanted to do async events, for example - an issue Bob also happened to raise at the time. The lower levels at this point, similar to appscript / aem are py2app.create_appbundle / modulegraph.find_modules / macholib.MachOGraph. You can do all the foot shooting you want with them! To give a practical example, let's say I want to write a GUI interface to py2app. My main dialog has some text fields and checkboxes for basic setup info, plus a table view listing all dependencies, allowing users to check/uncheck the items they want/don't want included. The obvious way to implement this would be to call modulegraph to generate the table content, then take the list of checked items and feed it to py2app's package-building function via an 'includeitems' argument. I really don't want or need py2app to run modulegraph a second time just because it's been welded into the basemost layer. That's sort of a backwards way to get at it.. given a proper refactoring of py2app, the "dependency finding" and "application building" would simply be split into two separate build phases (which means two command classes and a mess of additional code), so you'd run the dependency resolution phase, manipulate the py2app instance, and then run the build application phase. This is not currently the case, because py2app._run does both. For 0.1.7 I'll at least split this up into more pieces, so it has more useful hooks for subclasses. If nothing else, a more loosely-coupled architecture takes pressure off the developer to anticipate and support every single possible use to which a user might want/need to put their system and/or its components now or in the future. Distutils is the antithesis of loosely-coupled architecture. py2app is slowly being split apart into orthogonal components, but this flexibility would add a lot of complexity that I don't want to deal with at this point. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Where to put data
On Dec 21, 2004, at 6:57 PM, Charles Hartman wrote:
On Dec 21, 2004, at 3:32 PM, Bob Ippolito wrote:
On Dec 21, 2004, at 10:23 AM, Charles Hartman wrote:
(I also posted this to wxusers because it's sort of cross-platform
-- sorry if you're seeing it again.)
With an earlier app I wanted an external data file and everybody
told me to make it internal to the program (the app's Resources, I
guess) instead. I couldn't, then. Now with a new app I want to do
just that, but I'm not sure *how* to do it!
It's a file of data -- a Python dictionary object, after it's loaded
into memory -- which will grow and change as the app is used; when
the app terminates the data ought to be saved with it for next
time. In this case I don't want users fiddling with it apart from
the app.
What is the right way to do this? (What's the easy way?) Is there a
simple method that will work for both Mac and Windows (and Linux)?
The right way to do it is NOT to have this file inside your
application. You should *never* assume that you can write to your
own application bundle. You *should* have a way to create this file
from scratch (which may be a template file inside Resources, which is
never written to).
As others have said there are different places you should put this
file dependent on operating system..
On Mac OS X it should probably go in one of the "Application Support"
directories. It's common convention to only place plist formatted
files in the Preferences directory, so unless you're serializing this
dictionary as a plist, I suggest going with Application Support
instead of Preferences.
On other *nix, it would typically go into a ~/.yourapplication
directory.
And for Windows, somewhere in their home directory (at least on
NT-based Windows). Optionally, you could put it in the registry
instead, which may be a good idea, depending on how big it is
expected to get.
As far as writing to your own application goes, here's a short list
of why that's bad:
- Will not work from CD-ROM, compressed disk image, etc.
- Probably will not work multi-user
- Probably a bad idea if the application is on a network drive
- User may not have permissions to write to the application
- If you break it, you really broke it.
- It can look virus-like and be picked up as such (particularly on
Win32 if you're writing to the .exe file).
You should be able to trust the user not to fiddle with it apart from
the app. Especially if it's a pickle file. It will be pretty
buried, anyway.
OK, all this makes sense. But I'm startled to see how incredibly
gnarly it is to have any kind of data -- if you want to preserve
changes in the data, say by having a dictionary grow from one program
run to the next -- at least on more than one platform. Is this so
uncommon a pattern for applications? Oh well.
You make it sound much harder than it is. Yes, for the three major
platforms, there are three different canonical ways.
win32: registry is easy, especially using something like this:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/174627
OS X: NSUserDefaults is painless via PyObjC:
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/
ObjC_classic/Classes/NSUserDefaults.html
posix: otherwise, roll your own: appdir =
os.path.expanduser("~/.myapplication"); if not os.path.exists(appdir):
os.makedirs(appdir);
You could more or less use the dot directory method for all three
platforms if you were a cross-platform purist, it should work, at least
for NT-based windows. There's probably an abstraction for this
somewhere.
-bob
___
Pythonmac-SIG maillist - [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app Enforces Directory Structure?
e a better solution than that! Of course there is :) What I really need, I guess, is a way of specifying the source directory in which the modules in the "includes" list will be found. There doesn't seem to be any such option, though, and including a relative pathname in the "includes" list just generates an error when I try to build the app. The includes and excludes lists are Python module identifiers, not path names. Using a relative path name, anything that has a slash in it, or anything that starts with a dot or has more than one dot in succession, is of course an error because those are invalid Python module identifiers. from distutils.core import setup import py2app import sys # no longer necessary in 0.1.7 sys.path.insert(0, '../framework') setup( app = ["../framework/main.py"], data_files = ['../data'], ) % cd build % python setup.py py2app If you check out py2app trunk <http://svn.red-bean.com/bob/py2app/trunk> (as of revision 268), then the sys.path.insert(0, '../framework') is no longer necessary, and there is an example <http://svn.red-bean.com/bob/py2app/trunk/examples/structured/setup/ setup.py> that demonstrates the given use case (minus the bad form of having external data files). -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app Enforces Directory Structure?
On Dec 21, 2004, at 11:39 PM, Erik Westra wrote: I don't need to include anything else in the application, as the system will store the contents of the "data" and other directories outside of the application bundle itself. Don't do that. That's bad. Include the data and any other dependencies inside the application. Having them external and using an installer is not the Mac way to do things and I'm not going to help you do it. There was a similar discussion a while ago (weeks?) and I'm not going to have it again, so search the archives and argue with the past if you feel strongly in the other direction :) I agree that this isn't something worth arguing about (and I wouldn't expect you to help me do it, either!), but I just have one comment on this issue: in the system I'm porting to the Mac, the "data" might consist of 300+ megabytes of information held in an embedded SQLite database, along with hundreds of configuration files and dynamically-loaded Python modules (downloaded automatically from a web site as they are required). Our system is pretty darned complicated, and while I agree that it's not the Mac way of doing things, the architecture works well and our users really don't care much about the internal organisation. This isn't an application designed for mass distribution, so issues like this really aren't all that important to us. Anyway, topic closed. I certainly don't want to get into an argument about this... I just wanted to mention that there are designated places to put files like that, and "relative to wherever the application might be" is Not That Place. See the "Where To Put Application Files" section of `The Mac OS X File System`__. .. __: http://developer.apple.com/documentation/MacOSX/Conceptual/ BPFileSystem/index.html -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
On Dec 22, 2004, at 6:49, Ronald Oussoren wrote: On 21-dec-2004, at 23:42, has wrote: Chris Barker wrote: I originally came down on Has' side of this debate, but now think Bob has made the right choices, so I thought I'd add a couple comments. First, I'm a little unclear on what exactly Has wants. Could you clarify? Freedom, basically. It's easier to assemble a workflow by mixing and matching small, single-purpose components than to strip down a great big monolithic lump to get the pieces you want/need. If you're going to protect the end user from doing stupid things, that's great, but it should be done by the next layer up. Users who work at the top layer are protected; users who want/need to route around the 'dummy mode' restrictions can go in at the layer beneath. After all, it's the user's foot, and if they want to shoot holes in it in full knowledge of what they're doing then far be it for anyone or anything else to stand in their way. You obviously don't want it badly enough. Adding an option that will make the application not include stuff from site-packages is not much work, the patch is less that 100 lines (context-diff) and it took me less than half an hour to write it. You did write it incorrectly, though. You didn't make it imply --site-packages (non-working executables by default!), and you didn't check to see if it was compatible with Python 2.4. site.sitedirs, or anything equivalent, does not exist in Python >= 2.4. The former is easy to fix, but the latter is not. Additionally, the filter stack is stronger than "includes" so you certainly wouldn't be able to actually use it to do the use case that Has' fabricated. Needless to say, this functionality won't be popping up in 0.1.7 :) -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Re: [Pyqt-mac-list] Re: Eric 3
On Dec 22, 2004, at 9:46, Kevin Walzer wrote: Your path looks correctly set up to me. If you have the Pythonmac extensions installed, that's important, as my Eric3 app bundle actually makes use of the Python interpreter embedded in the PythonIDE. (That will be corrected in the next release of the entire package.) Therefore, it's not clear to me why Eric3 isn't seeing the Qt module, assuming that you're running the Eric3 version from /Applications. I'm wondering if the problem is, in fact, because you replaced the Apple - -installed version of Python with your own framework build. My package assumes the standard Apple installation, and I believe the PyQt source assumes this also. I'm not an expert on the internals of framework builds of Python, but my understanding is that ripping out Apple's build of Python can break things in unexpected ways. I'm copying my reply to the PythonMac and PyKDE lists: perhaps Jack Jansen (MacPython maintainer) or Phil Thompson (PyQt author) can shed more light on that aspect of your problem. I'll also see if I can find out more on my end. Jay Mutter wrote: | | Yes i did set QTDIR and referring back to Brian's previous post i do | think that it is some sort of path problem but i am not sure what. | | Anyway i only run Python 2.3.4 ( i terminated Apple's version long ago | to avoid problems) And yet, you caused them. This is probably the root if your problem. Messing with files in /System or /usr (except for /usr/local) is a recipe for disaster. There's always a better way to "replace" something, usually as simple as just putting /usr/local/bin (or other) early on in your PATH. My suggestion: Reinstall OS X, and don't screw it up this time. | from running env i got | | | PATH=/Developer/qt/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/ | usr/local/lib:/usr/local/pgsql:/usr/local/pgsql/lib:/usr/local/pgsql/ | include:/usr/local/pgsql/bin:/System/Library/Frameworks/ | Python.framework/Versions/2.3/bin:/library/frameworks/ python.framework/ | versions/2.3/lib/python2.3/site-packages What the heck is site-packages doing in sys.path? | DYLD_LIBRARY_PATH=/Developer/qt/lib: | PYTHONPATH=/system/Library/Frameworks/Python.framework/Versions/2.3/ | lib/python2.3/site-packages/ You should basically never set PYTHONPATH | from running $PATH i got | -bash: | /Developer/qt/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/ | local/lib:/usr/local/pgsql:/usr/local/pgsql/lib:/usr/local/pgsql/ | include:/usr/local/pgsql/bin:/System/Library/Frameworks/ | Python.framework/Versions/2.3/bin:/library/frameworks/ python.framework/ | versions/2.3/lib/python2.3/site-packages: No such file or directory running $PATH? What the heck? If you mean typing just $PATH at a bash prompt, of course it's going to say no such file or directory, it's not supposed to do anything useful. | My .bash_profile is | | # .bash_profile | PYTHONPATH=/system/Library/Frameworks/Python.framework/Versions/2.3/ | lib/python2$ | export PYTHONPATH These lines shouldn't ever be necessary | QTDIR=/Developer/qt | PATH=$QTDIR/bin:$PATH | DYLD_LIBRARY_PATH=$QTDIR/lib:$DYLD_LIBRARY_PATH | export QTDIR PATH DYLD_LIBRARY_PATH This looks right enough. Typically DYLD_LIBRARY_PATH is a terrible, awful, evil thing to do, but that's how Qt works. -bob ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Question about Pil and icns...
On Dec 22, 2004, at 7:09 PM, whamoo wrote: I've read that new beta of the Pil now add support for icns file format, nice, but in the code of the plugin i read that there is only the read support, so, i cannot convert icns in other format and vice-versa? And if i load icns, work on it, then i cannot save. Can someone tell me something about it? Someone have tried? That is correct, this is read-only support. You may not save icns files with the code in PIL. You could of course do it the native way, using Mac APIs, or just by dragging images into Icon Composer. My use case was that I had application resources in the canonical Mac OS X formats, and I wanted to re-use them in a Windows port of the software... so I wrote an icns decoder for these files (I used the 128x128 version of the icon in the UI), and all the string localization support from Foundation. I did of course need regular windows .ico files for the applications, but typically they only go up to 48x48, so I still wanted to re-use my .icns file rather than maintain a separate png of 128x128 for the UI. Needless to say, I did not need write support for ico, since all of my source icons were in icns format. What I would've liked is Windows XP .ico writing support, but I couldn't find that (or sufficient docs to implement it) *anywhere* and I ended up using a commercial package on Win32 to do it in batch. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Question about Pil and icns...
On Dec 22, 2004, at 7:45 PM, whamoo wrote:
On 23/dic/04, at 01:29, Bob Ippolito wrote:
On Dec 22, 2004, at 7:09 PM, whamoo wrote:
I've read that new beta of the Pil now add support for icns file
format, nice, but in the code of the plugin i read that there is
only the read support, so, i cannot convert icns in other format and
vice-versa? And if i load icns, work on it, then i cannot save.
Can someone tell me something about it? Someone have tried?
That is correct, this is read-only support. You may not save icns
files with the code in PIL.
But starting by reading a icns, i can save a png or jpg?
Yes, of course. Image.open('myapp.icns').save('myapp.png') will
probably Just Work.
You could of course do it the native way, using Mac APIs, or just by
dragging images into Icon Composer.
There is a fast way to produce icns starting from a 128x128 image
(format Png, jpg doesn't matter)?
What Mac Api i must use? I've search documentation, but found about
nothing (maybe I'm not able to search), i want write a python program
to convert images in icns in a background fast way, i can't drop 1000
image con icon composer =)
The easiest way would probably be to use IconFamily from PyObjC
<http://homepage.mac.com/troy_stephens/software/objects/IconFamily/>.
Carbon is always a pain in the ass, but the Icon Services functions may
be wrapped (not sure?). NSImage will load pngs and jpegs quickly and
easily.
-bob
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app Enforces Directory Structure?
On Dec 22, 2004, at 7:31 PM, Erik Westra wrote: Anyway, enough on this. I just wanted to thank you for the fantastic work you've done on py2app. I'm amazed -- I've packaged our company's various applications to work under Linux and Windows, using both the MacMillan Installer and py2exe, and py2app is by far the most trouble-free solution I've ever found (once you helped me out with getting sibling modules importing correctly). The system I bundled up last night makes heavy use of wxPython, docutils, PIL, pySQLite, and ReportLab -- and it all works perfectly right out of the box. The generated application is slightly bigger than the Windows version (the compressed disk image is 11 megs, compared with 8 megs for the equivalent installer under Windows), but that's acceptable. I can't believe that py2app simply handled all the dependencies and complexities of these various tools right out of the box. py2app has special considerations so that it (makes one hell of an attempt to) get wxPython, docutils, and PIL packaged correctly out of the box. There are a few other packages on its "hit list", but most stuff tends to Just Work without too much special casing. The downside is that in some cases, it will include more than you want (especially for PyQt), but at least your application will work. After using py2exe and reading the wiki, mailing lists, etc. I decided I would try very hard to make py2app do the right thing with the minimal amount of training (for both the user and the setup.py) and I think I've more or less done that. Most of the work I've done with regard to all this magic behavior is cross-platform and is mostly in the "altgraph" and "modulegraph" packages in the py2app distribution.. so if someone were so inclined, they could soup up py2exe, cx_Freeze, etc. leveraging this work. I might do this myself at some point, but not soon. Maybe I'll try and PEP it into Python 2.5. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] configure failing with Python 2.4
Reinstall Xcode and/or make sure you aren't using Fink or something which may have installed an alternate compiler (make sure "which cc" and "which gcc" point to /usr/bin). On Dec 23, 2004, at 10:23 AM, Kevin Dangoor wrote: Err, while this might be enough info for someone to go on, I just realized that there's not much there... I'm running Mac OS 10.3.6. I have XCode/Developer Tools installed, though that didn't seem to make any difference. I even tried moving my .bashrc and .profile files out of the way to be sure that those weren't causing any grief. Kevin Kevin Dangoor wrote: I'm thinking that I must be doing something simple wrong... hopefully that's the case. I downloaded the Python 2.4 source and tried to run a basic ./configure to see what I get. What I got was this error: checking for C++ compiler default output file name... configure: error: C++ compiler cannot create executables which appears to be caused by configure:1772: c++conftest.cc >&5 ld: can't locate file for: -lcrt1.o While I'm sure I can track that down, I figured that I must be doing something silly. Can anyone tell me what I'm missing? Thanks, Kevin ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
, so that the packages that need special casing (PIL, py, pypy, PEAK, docutils, etc.) have a way of presenting that information in a cross-platform cross-packager manner... but a typical application doesn't need such trickery, wxGlade is really the only one I've seen so far. Here's another whacky idea: why not get rid of the one-way source-code->build->finished-application workflow, and treat [certain types of] applications as simply another editable format? This is what AppleScript does, for example: write a script and save it as an applet, run it, drop the applet onto Script Editor, edit it some more, run it, etc. If it errors, a dialog pops up with an error description and an 'Edit Script' button that, when clicked, opens the script in SE for you with the faulty line already highlighted. Emulate Smalltalk a bit more, C a bit less. The more open, flexible and neutral tools like py2app are, the easier this kind of lunacy is to indulge. After all an idea is only stupid until you've tried it and find you really quite like it. :) That only works because everyone already has AppleScript and its IDE installed everywhere. We don't really even have an IDE worth using, and it's *probably* already possible to do this with emacs pdb integration, though I am not an emacs user (yet) so I can't say that with any authority. BTW. the GUI I'd like to see is a GUI that allows me to grafically construct setup.py files. I think the biggest problem with setup.py files is that they're unnecessarily complicated. The best way to simplify the setup process would be to simplify setup.py itself: push all the descriptive stuff - name, version, author, description, etc, etc. - into its own plaintext file so the only thing setup.py then has to deal with is any custom build code. Make the system simple enough that it doesn't require a wizard in the first place; a drag-n-drop GUI shell is then merely a pleasant (and newbie-friendly) convenience, rather than an awkward band-aid for deeper inadequacies. You can do that, with a setup.cfg file <http://docs.python.org/inst/config-syntax.html>. Honestly I can't see how you can really complain about setup.py being "complicated": from distutils.core import setup import py2app setup(app=['myscript.py']) What the heck is the problem with that? Understandably, it does get ugly when you need to specify py2app-specific options with options=dict(py2app=dict( ... )), but that *can* be nicely expressed in a setup.cfg [py2app] section, if you were so inclined. Additionally, as I said, I am not looking to replace distutils or write a front-end to distutils at this point, so the options syntax is a necessary evil. You can also do that with py2applet. It doesn't get much simpler than dragging your script plus resource files, optional icon and Info.plist onto py2applet and having an application bundle pop out in the same directory as the script. If the application can be packaged with a trivial setup.py (and most can), it just works. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
On Dec 23, 2004, at 5:25 PM, Dethe Elza wrote: With regards to refactoring setup.py files, here is what I've been using for several different apps. It has evolved as I've found new requirements. The only things I have to change from app to app (at this point) are the bits in ALL_CAPS at the beginning. I've been meaning to factor all of this into something like a function + .cfg, but haven't gotten there yet, so I just copy this into a new project and edit the few lines that change. HTH --Dethe ''' Run with: % python setup.py py2app ''' from distutils.core import setup import py2app NAME = 'Oblique Strategies' SCRIPT = 'oblique.py' VERSION = '0.3' ICON = NAME ID = 'oblique_strategies' COPYRIGHT = 'Copyright 2004 Dethe Elza' DATA_FILES = ['English.lproj', 'data', 'MainMenu.gsmarkup', 'MainWindow.gsmarkup', 'Credits.html'] plist = dict( CFBundleIconFile= ICON, CFBundleName= NAME, CFBundleShortVersionString = ' '.join([NAME, VERSION]), CFBundleGetInfoString = NAME, CFBundleExecutable = NAME, CFBundleIdentifier = 'org.livingcode.examples.%s' % ID, NSHumanReadableCopyright= COPYRIGHT ) app_data = dict(script=SCRIPT, plist=plist) py2app_opt = dict(frameworks=['Renaissance.framework'],) options = dict(py2app=py2app_opt,) setup( data_files = DATA_FILES, app = [app_data], options = options, ) This looks pretty good to me. I would put MainMenu.gsmarkup, MainWindow.gsmarkup, and Credits.html in English.lproj. -[NSBundle pathForResource:ofType:] and friends will look in localized directories.. so it saves you some typing and symlinks (in the case of an alias bundle). It's not really useful to set CFBundleExecutable. It doesn't matter what the executable's name is. It will default to the name of the script you give it. CFBundleName defaults to CFBundleExecutable, so if your script is named the same as your application you don't need to set this. CFBundleIcon will default to the CFBundleExecutable, so if you name your icon the same as your script and throw it in English.lproj, you don't need to set this. (reference py2app.apptemplate.plist_template and/or py2app.bundletemplate.plist_template to see this behavior for yourself) The copyright, bundle identifier, info strings, version, etc. are not defaulted to anything particularly useful.. so it is a good idea to set those in an application for general distribution. Since py2app doesn't really support multiple targets in a single setup(...) in a particularly useful way (and won't for some time, would require a hefty refactoring), you can make app = [SCRIPT] and add plist=plist to py2app_opt. -- For the plist template, in the future, it may be worthwhile to have some flag that can take a plist file and do PEP-292 on its string values <http://www.python.org/peps/pep-0292.html>. That way you can have a template plist file on-disk. I'm not sure precisely how this should work, but I'll probably look to Xcode for a friendly-ish way to do things. At some point, I may walk the module dependency graph to find direct dependencies in the objc module and do a little bytecode scanning to see if I can find "loadBundle" or "loadBundleFunctions" and automatically specify those as included frameworks. Alternatively, I might just make it necessary to put some kind of editor turd in the file like you have to do for text encoding (because that would work for ctypes dependencies too). That will likely happen at the same time PyObjC grows a smarter wrapper-generator that won't need to create extension modules as often (probably a PyObjC 1.3 feature). -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Let's discuss MacPython distributions for january
On Dec 23, 2004, at 6:28 PM, Michael Hudson wrote: Jack Jansen <[EMAIL PROTECTED]> writes: Second question: I think the solution to peaceful coexistence is that all Pythons adopt the solution sketched in Bob's mail <http://mail.python.org/pipermail/pythonmac-sig/2004-December/ 012292.html>. That discussion is rather technical, but what it boils down to is that all Pythons (on 10.3) build their extensions with "-undefined dynamic_lookup", thereby forestalling that extensions inadvertently pull in a second, different, Python framework. Side question: do we know yet if the Python shipped with tiger will get this right? I think this is checkable by people not under NDA, but if not at least those people who have seen Tiger previews can think about it :) They got it right in the Python 2.3.3 that was posted along with the Darwin 8.0b1 (?) sources, I'm pretty sure I pointed this out several times. There is no reason to believe they will screw it up between then (WWDC) and now :) -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Let's discuss MacPython distributions for january
ery controlled environment so I say let's just fix it in the right place. +1 for getting 2.4.1 and maybe 2.3.5 to build a usable destroot framework for Darwinports. +0 for any patches to 2.3.x explicitly for Fink or Darwinports. Darwinports uses -flat_namespace for 2.3.x, so that would have to be fixed too, which I'm sure has repercussions for people who already have Python 2.3.x installed and some modules built and also probably for other Portfiles. I don't know/care about Fink. This can be fixed on their own schedules by their own people once the patch is in 2.3.5 (if they decide to adopt a framework build). -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Let's discuss MacPython distributions for january
On Dec 23, 2004, at 7:01 PM, Charles Hartman wrote: Fixing this for 2.4.1 and 2.3.5 themselves is rather easy (and sketched in the mail mentioned above). Fixing this in the Apple-installed 2.3 is a bit more difficult, though. We can either modify it in-place (with admin permission) or do a complicated patch that Ronald came up with last year. While in general you should not muck with Apple-installed things I think that for this once I have a preference for the simple in-place modification over the slightly convoluted patch. Opinions, anyone? As a more or less perpetual newbie at this, much as I welcome the chance to upgrade, I cast my vote for a *reversible* change in the Apple-installed version. If I screw everything up, I'd like to be able to go back. Or, alternatively, make it impossible even for me to screw up. (Ha ha.) It's pretty much impossible to screw up. Basically it should be an installer .pkg that simply tosses a single file to a specific place, replacing what was there. There is no need to revert to the original version of this file because that one is half-broken to begin with. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Let's discuss MacPython distributions for january
On Dec 24, 2004, at 4:13 AM, Ronald Oussoren wrote: On 24-dec-04, at 1:01, Bob Ippolito wrote: +0 for any patches to 2.3.x explicitly for Fink or Darwinports. Darwinports uses -flat_namespace for 2.3.x, That's lame. Do you know why they do that? Legacy from 10.1.x or 10.2.x support, probably. We definitely used "-undefined suppress" all over the place, on purpose, in the 10.1 days. Possibly my fault? I know I compiled a lot of things "-undefined suppress" in those days because it was the first way that I could make things (kinda) work. A lot of ignorance on my part, and not enough documentation on Apple's :) I think this month, or maybe last, marks three years of Mac use for me... Sometime in the Summer was 3 years of Python :) -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Let's discuss MacPython distributions for january
On Dec 24, 2004, at 6:19 AM, Michael Hudson wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: On Dec 23, 2004, at 6:28 PM, Michael Hudson wrote: Jack Jansen <[EMAIL PROTECTED]> writes: Second question: I think the solution to peaceful coexistence is that all Pythons adopt the solution sketched in Bob's mail <http://mail.python.org/pipermail/pythonmac-sig/2004-December/ 012292.html>. That discussion is rather technical, but what it boils down to is that all Pythons (on 10.3) build their extensions with "-undefined dynamic_lookup", thereby forestalling that extensions inadvertently pull in a second, different, Python framework. Side question: do we know yet if the Python shipped with tiger will get this right? I think this is checkable by people not under NDA, but if not at least those people who have seen Tiger previews can think about it :) They got it right in the Python 2.3.3 that was posted along with the Darwin 8.0b1 (?) sources, I'm pretty sure I pointed this out several times. Quite possibly... There is no reason to believe they will screw it up between then (WWDC) and now :) Except that I tried to look for evidence of this in the WWDC source drop last night before posting and failed to find it... oh, is it in configure.ed? That seems a strange place to hang it, but oh well. I'm not going to bother looking again, but it was patched somewhere, and it linked extensions correctly. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
On Dec 26, 2004, at 10:46 AM, has wrote: Bob Ippolito wrote: The goal for 0.2.0, which I think has already been achieved (sans documentation), was to make it better than the alternatives for any platform. When do you think we'll start seeing some formal documentation for py2app? Write some and I'll include it. Right now the only documentation I'm working on is PyObjC, which does include some py2app related documentation. Look at all this another way: in an ideal world, developers and their applications wouldn't need to deal with any of this dependency crap _at all_. Each app would merely list its requirements and the system would magically conjour up suitable components upon request. In order for that to happen, either every user will have to have every version of every library already installed, or they would have to have the newest version of every library already installed (assuming that libraries would never be able to break backwards compatibility). Hardly. All you need is a CPAN-style central repository and a runtime extension that knows how to look it up and download components on-demand. That doesn't fix the multiple versions problem. You can already have that if you want it, but none of them are perfect and none of them are suitable for the common user on Mac OS X. Which is not to say that such a system could not be made suitable for the common user. All it needs is a will, and a really solid grasp of HCI (something OSS often isn't as strong on, but that's not insoluble either). It takes more than knowing how and wanting to do something to make it happen :) -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Debuggers wanted for fixup script
On Dec 26, 2004, at 6:15 PM, Jack Jansen wrote: I've added a script Mac/OSX/fixapplepython23.py to the CVS repository, only to the trunk for now, that will inspect and fix the Apple-installed Python 2.3 as per what we discussed here (making extensions build in a way that works, even if newer Pythons are installed). I'd like it if people could test the script, and test whether they see the warning (you need to run this script) if they do a framework install of 2.5a0 if their apple-python needs patching. Also, if people could run this on OSX 10.2 and 10.4, just to see that it doesn't cause any problems there, would be nice. The script does all sorts of error-checking (which hasn't been tested yet, of course:-), and I'm actually thinking of having the patch-installer (also discussed previously, this is a .pkg installer that will fix Apple-installed Python for people not building from source) also simply run this script, in stead of bluntly installing a modified copy of lib/config/Makefile. Opinions on this? Bluntly installing the Makefile will only be a problem if the user has an incorrect version of Mac OS X. The installer should check the version of the OS to be exactly 10.3.x as a precondition. This check can be done entirely in the Info.plist using functionality introduced in the Mac OS X 10.3 installer. There is no reason to have a script that does this, and error checking doesn't sound very useful as it will probably report "false positives" for people who have modified the Makefile in a similar but weaker or even mildly incorrect manner, but would still benefit from having the "officially patched" version. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] More testers needed: Fix installer
On Dec 27, 2004, at 11:31 AM, Michael Hudson wrote: Jack Jansen <[EMAIL PROTECTED]> writes: On 27-dec-04, at 15:04, Michael Hudson wrote: Indeed you can, and it seems to work (tm) on Panther here, but I'm *reasonably* sure you have chosen the wrong name for the package :) Yeah, consider that a working title. I may call it "The Installer that makes Apple-Installed Python on 10.3 build correct extension modules even after installing newer framework builds of Python". But suggestions for shorter names are welcome... But 10.3 is Panther, not Jaguar, right? Yes. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] More testers needed: Fix installer
On Dec 27, 2004, at 8:08 AM, Jack Jansen wrote: Ok, Bob, you win:-) I've created an installer package that replaces the Makefile after a simple test that you're actually running 10.3 and have that Makefile in the right place (i.e. didn't mess too much with your installation). If people could test this that'd be nice. Again, I'm especially interested in feedback from people running 10.2 or 10.4 (where the installer should refuse to run, with a decent message). You can find the package at <http://www.cwi.nl/~jack/macpython/JaguarPythonFix.dmg>. The Makefile is missing the MACOSX_DEPLOYMENT_TARGET=10.3 before the $(CC) .. which means that for most people, it won't compile extension modules, because not everyone has this set in their login scripts.. IIRC, The tradeoff is that distutils is *extremely* stupid and will no longer compile c++ modules correctly because it expects the compiler to be the first word in the variable expanded LDSHARED. This may or may not also be a problem with SciPy distutils. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] More testers needed: Fix installer
On Dec 27, 2004, at 11:47 AM, Michael Hudson wrote: On 27 Dec 2004, at 16:38, Bob Ippolito wrote: On Dec 27, 2004, at 11:31 AM, Michael Hudson wrote: But 10.3 is Panther, not Jaguar, right? Yes. That was rhetorical :) I'm not being completely thick, am I? The file should surely be called PantherPythonFix.dmg. Yeah, you are correct. Maybe while we're at it, we should also patch Info.plist. For this particular build, Python.framework has a CFBundleVersion and CFBundleShortVersionString of 2.2 :) -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] More testers needed: Fix installer
On Dec 27, 2004, at 11:59 AM, Ronald Oussoren wrote: On 27-dec-04, at 17:50, Bob Ippolito wrote: On Dec 27, 2004, at 11:47 AM, Michael Hudson wrote: On 27 Dec 2004, at 16:38, Bob Ippolito wrote: On Dec 27, 2004, at 11:31 AM, Michael Hudson wrote: But 10.3 is Panther, not Jaguar, right? Yes. That was rhetorical :) I'm not being completely thick, am I? The file should surely be called PantherPythonFix.dmg. Yeah, you are correct. Maybe while we're at it, we should also patch Info.plist. For this particular build, Python.framework has a CFBundleVersion and CFBundleShortVersionString of 2.2 :) How bad is that? That is, other than being ugly? Obviously not very, but Installer as of Mac OS X 10.3 has a requirements scheme that allows you to read keys from Info.plist bundles, so it might come in handy to keep this file synchronized with what it actually should be. It would also be an easy way to detect whether or not it has been patched. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] More testers needed: Fix installer
On Dec 27, 2004, at 12:09 PM, Ronald Oussoren wrote: On 27-dec-04, at 17:44, Bob Ippolito wrote: On Dec 27, 2004, at 8:08 AM, Jack Jansen wrote: Ok, Bob, you win:-) I've created an installer package that replaces the Makefile after a simple test that you're actually running 10.3 and have that Makefile in the right place (i.e. didn't mess too much with your installation). If people could test this that'd be nice. Again, I'm especially interested in feedback from people running 10.2 or 10.4 (where the installer should refuse to run, with a decent message). You can find the package at <http://www.cwi.nl/~jack/macpython/JaguarPythonFix.dmg>. The Makefile is missing the MACOSX_DEPLOYMENT_TARGET=10.3 before the $(CC) .. which means that for most people, it won't compile extension modules, because not everyone has this set in their login scripts.. IIRC, The tradeoff is that distutils is *extremely* stupid and will no longer compile c++ modules correctly because it expects the compiler to be the first word in the variable expanded LDSHARED. This may or may not also be a problem with SciPy distutils. I don't think this can be fixed without patching distutils. The patch shouldn't be too hard, but it may be too close to a 2.3.5 release to get it in there. Correct, however, it looks like Jack has already patched 2.5 so that it will set MACOSX_DEPLOYMENT_TARGET to the configure time value if not already set, so it can be injected into 2.3.0 with this pkg fix and backported to 2.4.1 and maybe 2.3.5. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] The versioning question...
On Dec 27, 2004, at 1:27 PM, Chris Barker wrote:
Bob Ippolito wrote:
That doesn't fix the multiple versions problem.
This is a big issue that the core Pythonistas don't seem to be
interested in addressing. It's odd, because I think it's a no-brainer
that python modules need to be versioned, and there needs to be a way
to have multiple versions co-existing and user (that is code)
selectable. They are just like dynamic libraries in this regard. I
think that's one reason Py2App and the like are so necessary now, it's
the equivalent of statically linking an app.
Particularly if Bob's idea of including PyObjC with MacPython gets
implemented, it would be great to have a versioning system in place
for it, so people could count on it being there, and not breaking apps
that use when a new version comes out.
PyObjC is pretty good about maintaining backwards compatibility..
there's still some garbage in there like objc.runtime that nobody
should be using anymore :)
Robin has added versioning to the latest wxPython, and I. for one am
ecstatic. It works great for me. I am generally using 2.5.3, but have
2.4.2 installed, and a number of my apps depend on it (on Linux
anyway, it's pretty useless on OS-X)
It's great to be able to put:
import wxversion
wxversion.select("2.4")
At the top of my apps, and know that they'll use the version of
wxPython I tested against.
Anyway, just a rant, but I do think something like this should be done
for any major packages that come with MacPython, like PyObjC.
It would be even better if there were a standard, Python-wide
approach, but my read of comp.lang.python tells me it ain't gonna
happen.
I don't particularly like this approach, it doesn't solve any problems
I've ever had, and it confuses stuff like py2app. You can still only
use one version of wxPython per Python process. For an application,
it's pretty easy to have it set a particular path on startup or include
a local copy of its dependencies (a la py2app).
The only "real" solution is with namespaces, like importing wx2_4
instead of wx, since extensions are effectively process-global.. but
that is an obvious maintenance problem.
Let's keep in mind how annoyed we all are that Apple supplied a python
that makes it difficult to install a newer python without breaking
things. Why should we not have the same standard for packages?
It's not really their fault that Python had bugs when they built it..
would've been nice if they were willing to upgrade, though.
-bob
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] More testers needed: Fix installer
On Dec 27, 2004, at 2:53 PM, Jack Jansen wrote: On 27-dec-04, at 17:44, Bob Ippolito wrote: You can find the package at <http://www.cwi.nl/~jack/macpython/JaguarPythonFix.dmg>. The Makefile is missing the MACOSX_DEPLOYMENT_TARGET=10.3 before the $(CC) .. which means that for most people, it won't compile extension modules, because not everyone has this set in their login scripts.. Ah, forgot about that one, thanks! I'll pull the installer, and I'll create a new one tomorrow (with a different name:-). The same problem holds for the fixapplepython script, so I'll fix that one too. What would be the easiest fix for 2.3.5: backporting the distutils fixes (so it'll set MACOSX_DEPLOYMENT_TARGET) or simply setting that variable in the $(LD) macro (through configure)? My vote is for the distutils fixes (that set the env var outside the LDSHARED or whatever), so that compiling c++ will definitely work. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] The versioning question...
On Dec 27, 2004, at 5:29 PM, Chris Barker wrote: Eric Nieuwland wrote: Would it be an idea to submit a PEP for extending the 'import' keyword? As I mentioned, my read on this is that it's not going to happen at the python level, at least not for a while. This is based on various threads in c.l.p, and maybe python-dev. So, while I still think it's important, I'm not going to try to work for it now. Even with wxPython, there was some resistance to the versioning idea, which as far as I could tell boiled down to: "It would be much better to keep packages backward compatible" Which is also kind of what Bob I. said about PyObjC. Personally I think the wx versioning mechanism is bad. It should've just been done with module names. Importing wx directly could reference the last version that was installed, and wx_2_4 could reference some specific version. The current versioning API is too "magical" and provides no means for static analysis without special-casing exactly the wx case. Then again, wx already does a lot of ridiculous magical things anyway that wreak havoc on application packagers, so why not make the mess even bigger? More fun for us! However, while backward compatibility is great, you are going to want to break it some time. In the wxPython case, there was a lot that changed between 2.4.2 and 2.5.1 and 2.5.2, etc. This was an extreme case, but while maybe it would be a good idea to keep backward compatibility from 2.4.* to 2.5*, at some point, maybe version 3.0, you'll want to break it, and then it would be good to have a system in place. That's when you change the name of the top level module or package... It's the only solution that actually works, but people like to cry about it because it's ugly :) I just seems obvious to me that you should be able to upgrade a component on your system, whether it be a library, or a python module, without breaking anything that depends on the older component. That's why we have version numbers on dynamic libs. Whether it was Apple's fault or not, it's still been a pain that I can't just upgrade python on my OS-X box. What If Apple some day included PyObjC version X.y and uses it for some system components. Wouldn't you like to be able to upgrade to PyObjC version W.z on your own schedule, not Apple's? Upgrading is almost unilaterally a bad idea. Even backwards compatible libraries can cause breakage in applications that depend on misfeatures of a previous version. What you really want is to be able to run multiple versions of stuff in parallel, and that pretty much works. Yes, you need to patch Python if you want the older version to still be able to compile extensions, and that's more or less our fault. Other than that, having parallel Pythons works just fine. For third party packages, Apple seems to install them in the normal place (directly in site-packages or some equivalent referenced by a pth). It would be possible to upgrade these by normal means (replace).. however, by doing that, you're potentially breaking any installed software that uses it. If you want bleeding edge, or the dusty old past, you MUST run it in parallel, whether that's by having a separate Python installation or a way of flipping around sys.path. Except for modules that are specifically designed to run in parallel with other versions of themselves (by naming convention), you simply CAN NOT have two versions of the same thing available. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Python-Dev] Re: [Pythonmac-SIG] The versioning question...
On Dec 27, 2004, at 8:45 PM, Chris Barker wrote: The versioning system that wxPython now has is quite nice, and seems to fit most people's needs well. However, it's also quite new, and who know what problems will arise. For those interested, here's a synopsis. http://wiki.wxpython.org/index.cgi/MultiVersionInstalls I just cleaned up a bunch of spelling on that wiki page and rewrote the "what about py2exe" section. It now mentions py2app, is (hopefully) written more clearly, and includes an easier alternative for bundling the desired version of wxPython (wxversion can be used from setup.py). -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app error with _py_suffixes
On Dec 28, 2004, at 12:05 PM, Kevin Dangoor wrote: First of all, thanks for all of the work put into py2app! Hard to imagine how much time it would have taken me to figure out all of the various things that it does (particularly since I'm new to Mac development). I was just going to rebuild an app and ran into this error: File "/purelib/py2app/py2app/util.py", line 203, in byte_compile NameError: global name '_py_suffixes' is not defined It was trying to byte compile a ".pyc" to a ".pyc" I don't see _py_suffixes defined anywhere... Thanks again for the cool tool I have no idea. I'm not sure what version you are using, and svn trunk doesn't reference a "_py_suffixes" anywhere from any file. Try upgrading to svn trunk or wait for an 0.1.7 release later this week. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app error with _py_suffixes
On Dec 28, 2004, at 12:14 PM, Kevin Dangoor wrote: Kevin Dangoor wrote: First of all, thanks for all of the work put into py2app! Hard to imagine how much time it would have taken me to figure out all of the various things that it does (particularly since I'm new to Mac development). I was just going to rebuild an app and ran into this error: File "/purelib/py2app/py2app/util.py", line 203, in byte_compile NameError: global name '_py_suffixes' is not defined It was trying to byte compile a ".pyc" to a ".pyc" I don't see _py_suffixes defined anywhere... One more bit of relevant info... I just noticed that the file in question was a ".ptl" file (from Quixote) that was compiled into a ".pyc". That would probably explain it. py2app may very well not be compatible with alternatively compiled bytecode, I will have to look into it. Do you know if compiled ptl is compatible with py2exe? -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Using TkAqua /Tkinter with custom Python 2.2
On Dec 28, 2004, at 2:46 PM, Andrew Roazen wrote: I was referred here by Kevin Walzer at tcl-mac's mailing list: > Can any of the core MacPython developers take a look at this thread and > give us the Pythonic viewpoint on these questions? (hooking TkAqua and > Tkinter into an old version of Python for the Mac with undocumented, > proprietary modifications: what issues should he consider?) Backstory: Curious Labs develops a 3D animation program called Poser. In 2000 they released a Windows/OS 9 version with a custom Python that has hooks to Poser internals. This version was succeeded by Poser 5 in 2002, but only for Windows (for reasons I won't go into here). When Poser 5 finally had a Mac release in 2003, it was Carbon for OS X. The Python shipping with it is a slightly modified MacPython 2.2 for Carbon. However, a growing number of Poser Python scripts are relying on Tkinter front ends and Tkinter was never successfully Carbonized. Poser's date for moving to Cocoa is fuzzy right now. For short term compatibility it would be desirable to fix this problem, perhaps using TkAqua. To reiterate Kevin's question: Assuming Curious Labs' modifications to MacPython 2.2 were nothing outside of Poser internals (i.e. variables to control character/prop/lighting values), what issues are involved in plugging TkAqua/Tkinter into this MP2.2 aka PoserPython? Presumably this Python is CFM based, because their OS 9 version must have been. That is likely to make it significantly harder, and CodeWarrior will probably be necessary in order to compile this Python and its extensions. I'm not sure if anyone aside from Jack and Just even remember how to do that.. I sure don't :) -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2applet question
On Dec 28, 2004, at 4:14 PM, Kevin Walzer wrote: Kevin-Walzers-Computer:~/Desktop/eric-3.5.1/eric kevin$ py2applet eric3.py from: can't read /var/mail/py2app.scripts.script_py2applet /usr/local/bin/py2applet: line 3: syntax error: unexpected end of file Sounds like the hash-bang is missing from /usr/local/bin/py2applet. I'm not sure why that is, I haven't been able to reproduce with svn trunk. ~from UI.SingleApplication import SingleApplicationClient ~ File "UI/SingleApplication.pyc", line 17, in ? ~ File "Preferences/__init__.pyc", line 1270, in ? ~ File "Preferences/Shortcuts.pyc", line 17, in ? ImportError: No module named XML.XMLUtilities This is because whatever you're wrapping is making some crazy non-import-bytecode based import of some XML package. You can not use the GUI py2applet with such an application, and you should probably create a setup.py. The command-line py2applet might be able to package such an application like this: % py2applet eric3.py --includes='XML.*' It really depends on what the XML is and how it's structured. I'm using the newest version of py2app (.1.6) that has the support for PyQt built-in. I'm just putting the name of the main script in the setup.py file, and not adding anyting else. Is there something special I need to do with the XML module in terms of referencing it in the setup.py script? I've actually run into this problem (w/XML modules) with other apps I've tried to build with py2app, so I'm not sure what to do. Where the heck does this XML module come from anyway? It's not in the standard library or anything else I've ever used. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Qt is
On Dec 28, 2004, at 8:07 PM, Charles Hartman wrote: commercial, I take it. I was hoping to try Kodos, which looks like a helpful learning tool. So, not knowing anything about it, I followed the trail from Kodos, to PyQt, to SIP, to Qt, to the little box that wants $1,550. Oops, I think I just stepped out of the GNU world & into the old. Qt is dual-licensed software. For X11 and Mac OS X, it is available under the terms of the QPL. You might want to look at RegExPlor <http://python.net/~gherman/RegexPlor.html>, which does more or less the same thing but is PyObjC based. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app error with _py_suffixes
On Dec 28, 2004, at 10:18 PM, Kevin Dangoor wrote: Bob Ippolito wrote: On Dec 28, 2004, at 12:14 PM, Kevin Dangoor wrote: Kevin Dangoor wrote: I don't see _py_suffixes defined anywhere... One more bit of relevant info... I just noticed that the file in question was a ".ptl" file (from Quixote) that was compiled into a ".pyc". That would probably explain it. py2app may very well not be compatible with alternatively compiled bytecode, I will have to look into it. Do you know if compiled ptl is compatible with py2exe? I'm using py2app 0.1.6 (just downloaded today). At least in that version, there's a _py_suffixes referenced. I had my build script drop a _py_suffixes into the util module and that worked fine. Yuck. Well, svn trunk is significantly different and 0.1.7 will be out any day now (whichever day PyObjC 1.2 comes out). Quixote's ptl compiler includes a handy function that compiles every ptl in a directory. Precompiling the ptls worked fine with py2app! That's a much more pleasant solution (to me, at least) than dropping the files in next to the app, which is what was suggested for py2exe. Interesting, I'll have to look at Quixote at some point to see if I can integrate that as a recipe. If your app is open source, could you point me to its source so I can make it a use case? -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2
On Dec 28, 2004, at 4:30 PM, [EMAIL PROTECTED] wrote: Update of /cvsroot/python/python/dist/src/Mac/OSX In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9229 Modified Files: fixapplepython23.py Log Message: Just passing -undefined dynamic_lookup isn't enough: we also need to set the MACOSX_DEPLOYMENT_TARGET environment variable to 10.3 when calling the loader. And we do this with "env" because distutils apparently doesn't understand environment variable assignments before command names. This is the wrong fix. Distutils is dumber than you think. This patch just breaks C++ compilation in a different way. The correct solution is a patch to distutils of some kind. from distutils/unixccompiler.py:174 if target_lang == "c++" and self.compiler_cxx: linker[0] = self.compiler_cxx[0] self.spawn(linker + ld_args) "linker" is the variable expanded LDSHARED (or whatever comes out of sysconfig.customize_compiler). -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Popen2
On Dec 29, 2004, at 3:12 AM, François Granger wrote: I am trying to use popen2.popen3 and I am stuck. Don't! Use subprocess instead. Read this thread <http://mail.python.org/pipermail/pythonmac-sig/2004-October/ thread.html#11869> for the last discussion on this topic (that I recall, anyway). -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How badly is _locale broken?
On Dec 29, 2004, at 4:50 AM, Ronald Oussoren wrote: On 28-dec-04, at 23:11, Brett C. wrote: I am planning to attempt to fix the _locale module (which 'locale' itself imports and uses) for OS X. As of this exact moment I am planning just fixing localeconv (thanks to CFNumberFormatter and setlocale still at least storing the supposed locale, even if it does ignore it), but I realized other stuff might be broken. Since I never personally use the module, does anyone know the extent of the breakage? Obviously I would rather just have to fix localeconv and keep my life simple, but if it is more extensive I can see what I can do. Not linking with the CoreServices and Foundation frameworks would do the trick. That might cause problems elsewhere though :-(. I think someone said this is fixed on 10.4, so you can just wait a while and it'll probably fix itself using the generic unix code. Yes, not linking to CoreFoundation will cause problems, because *something* will inevitably link to CF. For example, the py2app bootstrap will link to CF. A bunch of the extension modules in MacPython also independently link to CF-using frameworks. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] dyld trying to link against wrong version of Python
anyone knows how to do that, it could also be a solution, or not. This is a bug in Python 2.3.0 that has been discussed A LOT on this list, most recently <http://mail.python.org/pipermail/pythonmac-sig/2004-December/ thread.html#12403>. Your "phantom framework" problem is because you didn't clobber the build directory for numarray. It cached the incorrectly built extensions that were compiled when the Python 2.4 framework was present. Kill the build directory and compile/install again. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2
On Dec 29, 2004, at 5:23 AM, Jack Jansen wrote: On 29-dec-04, at 4:35, Bob Ippolito wrote: This is the wrong fix. Distutils is dumber than you think. This patch just breaks C++ compilation in a different way. The correct solution is a patch to distutils of some kind. from distutils/unixccompiler.py:174 if target_lang == "c++" and self.compiler_cxx: linker[0] = self.compiler_cxx[0] self.spawn(linker + ld_args) "linker" is the variable expanded LDSHARED (or whatever comes out of sysconfig.customize_compiler). Bah! Any suggestions as to what to do to get c++ compilation fixed? I can think of two ways: 1. Patch distutils to actually do os.environ['MACOSX_DEPLOYMENT_TARGET'] = '10.3' because CCompiler.spawn doesn't take an environment dict. 2. Patch distutils to skip over environment variables (basically change that "0" into something smarter). This is probably less desirable because who knows where this happens, and who knows what third party compiler subclasses used this original stupid code as a template. In either case, setting the environment variable should only be done if it's not already set, and it should raise if is set to anything lower than 10.3. For example, an existing MACOSX_DEPLOYMENT_TARGET variable of 10.4 should be allowed. Values smaller than 10.3 should not be allowed because they are incompatible with the linker feature we're trying to enable. Also, could you point me to a readily available extension package that uses c++? I have no idea, but I remember this issue was brought up at some point during one of the many discussions of this issue. I think it was also mentioned that SciPy's distutils extensions (or is it a fork?) does something similarly stupid when frobbing in a Fortran compiler. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How badly is _locale broken?
On Dec 29, 2004, at 5:32 AM, Ronald Oussoren wrote: On 29-dec-04, at 11:23, Bob Ippolito wrote: On Dec 29, 2004, at 4:50 AM, Ronald Oussoren wrote: On 28-dec-04, at 23:11, Brett C. wrote: I am planning to attempt to fix the _locale module (which 'locale' itself imports and uses) for OS X. As of this exact moment I am planning just fixing localeconv (thanks to CFNumberFormatter and setlocale still at least storing the supposed locale, even if it does ignore it), but I realized other stuff might be broken. Since I never personally use the module, does anyone know the extent of the breakage? Obviously I would rather just have to fix localeconv and keep my life simple, but if it is more extensive I can see what I can do. Not linking with the CoreServices and Foundation frameworks would do the trick. That might cause problems elsewhere though :-(. I think someone said this is fixed on 10.4, so you can just wait a while and it'll probably fix itself using the generic unix code. Yes, not linking to CoreFoundation will cause problems, because *something* will inevitably link to CF. For example, the py2app bootstrap will link to CF. A bunch of the extension modules in MacPython also independently link to CF-using frameworks. I know that. But not linking with CoreServices should fix _locale for python scripts that don't use mac-specific features. Well, my patch to remove all non-libSystem dependencies from the Python core was accepted for Python 2.4, so we are already at this point. However, the mac toolbox functions can lazily import CF-using modules. I think the core probably uses some of these functions. Last I remember, the locale module itself linked to CF (directly or indirectly) so it could guess what the current locale should be :) The correct fix would probably use CFLocale to implement the _locale module on OSX. Yes, that would be a good fix. Alternatively, we could just punt on the issue and say "you need to use 10.X in order to have a working locale module", where 10.X is the version that Apple fixes CF. X is obviously greater than 3, but I don't think it will be much greater. It's been broken for this long, and Brett C. said he doesn't use the locale module, so it may be too much effort for too little reward. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How badly is _locale broken?
On Dec 29, 2004, at 6:06 AM, Michael Hudson wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: Alternatively, we could just punt on the issue and say "you need to use 10.X in order to have a working locale module", where 10.X is the version that Apple fixes CF. X is obviously greater than 3, but I don't think it will be much greater. It's been broken for this long, and Brett C. said he doesn't use the locale module, so it may be too much effort for too little reward. It would be nice if the unit tests stop failing, though. So skip them and disable (or at least throw up a warning that says those locale functions don't actually work) the module if not using 10.X or later. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] BuildApplet in next distro of MacPython?
On Dec 29, 2004, at 11:58 AM, Kevin Walzer wrote: I'm curious about whether BuildApplet and PythonIDE will be included in the next iteration of MacPython, or whether these will be replaced by py2app and PyOxide. Although I know these are old technologies, especially BuildApplet, I'd like to request that they be retained, even if they're not updated or enhanced. Nothing is going away anytime soon. I'm sure your concerns will be addressed by the time this is even an issue, assuming that you are willing to request features and report bugs to py2app. The reason I'm asking is that I make extensive use of BuildApplet in the packages I maintain. I've had inconsistent luck with BundleBuilder, py2app, and py2applet--mostly bad luck. If you give up on reporting issues and whatnot with py2app it's not ever going to suit your needs. py2app's alias build mode (-A) is equivalent to what BuildApplet does *except* the output isn't *ever* portable to other machines because it keeps references not copies to the scripts and data files. It works perfectly fine for "from IDE" use. The nice thing about BuildApplet that it is, in fact, very simple, even dumb, in creating applications: it saves the script in question, that's it. It then becomes a simple matter to add the additional scripts that come with an application to the app bundle in the appropriate directory, to edit the info.plist file, to change the icon, etc. In short, I have control over almost the entire process of packaging. And I've documented this process pretty thoroughly at my website. Adding dependencies by hand is really sketchy. In order to do it right, it basically has to be all or nothing (until py2app has an interactive mode anyway). Right now py2app's "nothing" option is not portable to other machines. However since py2app alias bundles are so quick to create and the output is so small you can just make one at the destination machine. Which of course, already has "everything", including py2app. It is not even possible to correctly include the following, very common, kinds of dependencies after-the-fact: 1. Are compiled with an unpatched Python or 2. Are compiled in a 10.2 compatible way 3. Depend on third party dylibs By "not even possible" I mean that you won't do it correctly unless you REALLY know what you are doing with install_name_tool, etc. If you did, you would probably rather had py2app do it for you anyway, because I guarantee it's not any fun. I realize there are tradeoffs with this approach. Apps I bundle with BuildApplet don't have their external dependencies included (wxPython, PyQt, whatever). But if those external dependencies are installed on the ~ user machine, then the BuildApplet process works flawlessly. That's an extremely big if and is only really relevant if you're distributing software to other Python developers or inside of a controlled organization. py2app's alias mode works a lot like that, except it's not portable to other machines because aliases and symlinks are used internally. However, in both scenarios where BuildApplet's output is useful, this is actually reasonable. Python developers can type "python setup.py py2app -A" themselves. In a controlled organization, this could be done as part of the installation process for your application, since py2app and everything else will already be installed by other means. py2app is a lot more elegant and smarter in what it does in terms of packaging, but it's also more complex. That is, if there's an error, it's very hard--at least for me--to debug. The build process dies. I tested this yesterday with both py2app and py2applet with Eric3, an application I have successfully with BuildApplet. With both py2app and py2applet, something didn't get included, even though Bob has now added PyQt support to py2app. Neither he nor I could figure out what the problem was. The result was that the bundle created with py2app crashed, while py2applet just died during the build process. If you want "stupid" output from py2app, pass --site-packages. This means your applications will work locally, since the missing modules will be searched for in the normal manner, but your application now has a high probability of not working on another machine. Hopefully it's obvious why this is not the default. Since you were unwilling to even post the results of my suggestion yesterday, implicating me in "neither he nor I could figure out..." is a bad way to put it. Basically, you haven't yet done anything beyond your initial message to help me figure it out, and are throwing your hands up because I didn't immediately know what kind of craziness is involved in Eric3 and how that affects py2app off the top of my head. That said, the way to solve this
Re: [Pythonmac-SIG] BuildApplet in next distro of MacPython?
On Dec 29, 2004, at 1:40 PM, Kevin Walzer wrote: | py2app is a better choice than BuildApplet for PyOxide. Adding support | for BuildApplet before or in addition to py2app seems backwards. Adding | support for alias mode is definitely important for something like | PyOxide, which would suit your use case (aside from machine | portability), and machine portability with a stupid bundle isn't really | very useful or important, as I mentioned above. | | Perhaps in the future py2app will have a mode similar to alias mode that | makes the stupidest dependency-free "self-contained" bundle that could | possibly work (locally), but I am still unconvinced that this is more | useful than dangerous and confusing. If "save as applet" from PythonIDE is as non-portable as you say, I'm curious why I haven't gotten any bug reports on the apps I've built that way. I do try to make the external dependencies (MacPython add-ons, wxPython, Tk, PyQt) explicit, and I do provide links for folks to download and install them. Perhaps that's the reason? I said that py2app's alias mode is non-portable. BuildApplet creates portable applications that work if all dependencies are expected to already be installed. You probably haven't received bug reports because you have an audience of developers who are used to and willing to install all these dependencies. Pointing them all out probably helps, too. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] BuildApplet in next distro of MacPython?
On Dec 29, 2004, at 4:29 PM, Kevin Walzer wrote: Bob Ippolito wrote: | I said that py2app's alias mode is non-portable. BuildApplet creates | portable applications that work if all dependencies are expected to | already be installed. Hmmm. That's a good argument to retain BuildApplet in some form. Not really, if anything else, it is an argument to add a "stupid" mode to py2app. However, as I've said before, I'm hesitant to prioritize that since its usage is limited to two targets: very controlled environments, and python software developers. In both cases, it's currently possible and likely better to specify your expected environment by exclusion. In other words, add an exclude for each module/package you expect the user to already have. This is counter to the "ease of use" of BuildApplet, but given how uncommon this use case is, how hard it is to test a BuildApplet application for dependencies (you need two machines), I'd rather leave it as-is for a while because people distributing applications built in this style should at least know what their dependencies are. In your case, you already have to know the definitive list of requirements for documentation purposes, so it's not hard to move that down to the setup.py as excludes. Back to the original problem, you said that these XML modules are specific to Eric3, which means that somewhere along the way Eric3 is doing some non-statement imports or exercising some bug in py2app 0.1.6. Try it again with py2app 0.1.7, which was soft launched earlier today in expectation of a PyObjC 1.2 release later today or tomorrow morning (when I've built+tested the Jaguar package). If that doesn't work, I'll take a look at Eric3 myself to see what's going on and either provide a workaround or compensate for what's going on in py2app 0.1.8. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How badly is _locale broken?
On Dec 29, 2004, at 6:06 PM, Jack Jansen wrote: On 29-dec-04, at 11:32, Ronald Oussoren wrote: I know that. But not linking with CoreServices should fix _locale for python scripts that don't use mac-specific features. If I understand correctly it's the loading of CoreServices that causes the _locale problem, right? If that's indeed the case then I think not linking with CoreServices would make this problem even worse: imagine a scenario where an unsuspecting user has working code in a toy app, but it fails when used in his GUI app (which happens to use CoreServices). Or code that works standalone but not in . IIRC it's the CoreFoundation loader that abuses some private functionality that forces the C locale. Simply faulting on any symbol in CoreFoundation will cause this loader to run. I think CoreServices uses CoreFoundation, which may have caused the confusion, but I'm pretty sure it's a CoreFoundation issue. Fortunately, the _locale module links to CoreFoundation (directly or indirectly) anyway to get the current locale (or something like that). The way it does things on current versions of OS X probably doesn't do anything useful, but at least it's broken even with the reduced core dependencies in Python 2.4. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: The PantherPythonFix installer and C++ extensions
On Dec 29, 2004, at 6:25 PM, Jack Jansen wrote: On 29-dec-04, at 11:40, Bob Ippolito wrote: [Bob notes that my PantherPythonFix installer will break C++ compilation because distutils simply replaces the first component of LDSHARED with "c++"] Any suggestions as to what to do to get c++ compilation fixed? I can think of two ways: 1. Patch distutils to actually do os.environ['MACOSX_DEPLOYMENT_TARGET'] = '10.3' because CCompiler.spawn doesn't take an environment dict. 2. Patch distutils to skip over environment variables (basically change that "0" into something smarter). This is probably less desirable because who knows where this happens, and who knows what third party compiler subclasses used this original stupid code as a template. Both of these mean that "the simple installer that just puts a new Makefile into lib/python2.3/config" has just gone out the window:-( Yeah.. I'd rather have broken C++ support than broken linker support though.. so this patch is better than no patch. I think I have a better alternative to both of these suggestions (basically what I just checked in for 2.5a0: allow the Makefile to force a setting for MACOSX_DEPLOYMENT_TARGET, unless it was set already), but that still leaves the problem that there's more files to patch. We could of course replace sysconfig.py and sysconfig.pyc in place, but I don't feel happy about that. (So: please argue that it isn't a problem). I'm +1 for replacing sysconfig.py. It's known to be exactly the one included with 2.3.0. The user gets what they deserve if they made their own changes to sysconfig.py here. Or we could install a newer, patched distutils into /Library/Python/2.3. But that has the problem that it'll obliterate any other newer distutils the end user may have installed. Also not a good idea. -1.. you would also need to use a weird .pth hack to make sure it gets into sys.path before stdlib.. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] BuildApplet in next distro of MacPython?
On Dec 29, 2004, at 11:48 PM, Donovan Preston wrote: On Dec 29, 2004, at 10:40 AM, Kevin Walzer wrote: Perhaps I wasn't clear. I don't add *any* dependencies except those that ~ come with the application itself: i.e. I simply copy the directory structure of the application (wxGlade, Pears, what have you) into the app bundle. Any external libraries such as wxPython have to be installed separately by the end user. You can just as easily do this with app bundles built by py2app. Yeah, if your main script doesn't have any detected dependencies.. or they're explicitly excluded. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] The PantherPythonFix installer and C++ extensions
On Dec 30, 2004, at 11:44 AM, Jack Jansen wrote: On 30-dec-04, at 10:02, Ronald Oussoren wrote: In the quick-and-dirty-hacks category: you could write two simple shell-scripts that start the compiler with the right environment variables: run-cc: #!/bin/sh env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "[EMAIL PROTECTED]" run-c++: #!/bin/sh env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "[EMAIL PROTECTED]" Here's an even better idea (I think), please think about whether it would fly: In the Makefile we not only change LDSHARED and BLDSHARED to start with " env MACOSX_DEPLOYMENT_TARGET=10.3", but also CXX. That'll teach distutils to fiddle with our command lines:-) Only question is: would this have any adverse side efffects? Same problem. If you replace the first word, you'll end up with either "g++ gcc..." or "g++ MACOSX_DEPLOYMENT_TARGET=10.3 gcc..." depending on whether "env" was used or not. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] The PantherPythonFix installer and C++ extensions
On Dec 30, 2004, at 2:52 PM, Ronald Oussoren wrote: On 30-dec-04, at 18:49, Bob Ippolito wrote: On Dec 30, 2004, at 11:44 AM, Jack Jansen wrote: On 30-dec-04, at 10:02, Ronald Oussoren wrote: In the quick-and-dirty-hacks category: you could write two simple shell-scripts that start the compiler with the right environment variables: run-cc: #!/bin/sh env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "[EMAIL PROTECTED]" run-c++: #!/bin/sh env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "[EMAIL PROTECTED]" Here's an even better idea (I think), please think about whether it would fly: In the Makefile we not only change LDSHARED and BLDSHARED to start with " env MACOSX_DEPLOYMENT_TARGET=10.3", but also CXX. That'll teach distutils to fiddle with our command lines:-) Only question is: would this have any adverse side efffects? Same problem. If you replace the first word, you'll end up with either "g++ gcc..." or "g++ MACOSX_DEPLOYMENT_TARGET=10.3 gcc..." depending on whether "env" was used or not. Wouldn't you end up with 'env MAC.. gcc' when linking c++ extensions? distutils changes the first word which is 'env' in either case. Oh.. right. But then given a bunch of .o files, it will probably not link in libstdc++. Who knows what SciPy will do with Fortran... -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Py2App 0.1.7
On Dec 30, 2004, at 5:25 PM, Chris Barker wrote: I just installed Py2App with the installer, but when I tried to use it I got: Traceback (most recent call last): File "setup.py", line 21, in ? import py2app File "/purelib/py2app/py2app/__init__.py", line 33, in ? File "/purelib/py2app/py2app/install.py", line 15, in ? File "/purelib/py2app/py2app/command/__init__.py", line 1, in ? File "/purelib/py2app/py2app/build_app.py", line 20, in ? File "/purelib/py2app/modulegraph/find_modules.py", line 21, in ? File "/purelib/py2app/modulegraph/modulegraph.py", line 15, in ? ImportError: No module named ObjectGraph My first question was: "where the heck is /purelib ?" That's an artifact of how the distutils install command compiles .py files under bdist_mpkg, eventually I'll fix that. So, am I right that those older versions of altgraph and macholib were installed by an older Py2app? Yes, probably 0.1.5. It has been in the py2app directory since 0.1.6. If so, some sort of waring should be put in about that. I think that they should've been removed by the installer.. Oh well, there probably isn't much I can do about it now. Hopefully most people are already up to date or don't have it installed. Also, while it's probably a good idea that you're now putting those packages inside the Py2app directory, it would probably be better to load them as: from Py2app.macholib import MachOGraph So that you know you're getting the version you installed for Py2app. py2app is not a package, it's just a directory pointed to by a pth. I "own" all these packages, so this is not a problem, except in the rare-ish case where an old version is installed. By the way, if I needed altgraph for something else, I'd now be kind of screwed. Tome, this supports the argument I've been making for versioning. If we had a standard approach for versioning python packages, you could have the Py2app installer install the version of altgraph (and whatever else) it needs, and not screw up an exiting installation that other folk's code might be depending on. The packages altgraph (my fork of "graphlib"), modulegraph, bdist_mpkg, macholib, and py2app are all exclusively maintained by me, and are only released as part of py2app. You don't need them for "something else", especially an older version. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Py2App 0.1.7
On Dec 30, 2004, at 7:31 PM, Chris Barker wrote: Bob Ippolito wrote: py2app is not a package, it's just a directory pointed to by a pth. but couldn't be? I why isn't it in site-packages anyway? Though I imagine you have a good reason, I'd like to know what it is. The whole pth thing seems kind of clunky to me. I'm using a pth file so that I can put five separate packages in the same place that don't have a whole lot to do with each other but should be distributed together. Adding an extra level of nesting to the python namespace would just be a pain in the ass for me and no real help to anyone. The packages altgraph (my fork of "graphlib"), modulegraph, bdist_mpkg, macholib, and py2app are all exclusively maintained by me, and are only released as part of py2app. So putting them in the py2app dir, where you have them now, makes sense. Exactly, that's what the pth file is for. You don't need them for "something else", especially an older version. When this problem arose, I just did a quick google search for altgraph, and it looked like a generally useful package, so It wasn't clear that it is used exclusively for py2app. Sounds like you found another package on google.. unless the references are in my svn repo or blog, it shouldn't be mentioned anywhere. It is pretty useful, but I'm not willing to support it. If you want stability or documentation, you're better off using graphlib. Even though I have made some enhancements, I reserve the right to do whatever I want to altgraph at this time. Oh well, I've got it all working now, very well, as a matter of fact. Now I just need to figure out how to give my app an icon. 1) make an icns file 2.a) name it the same thing as your main script and add it to data_files or resources 2.b) specify it with the iconfile option 2.c) add it to data_files or resources with any name and specify it with a CFBundleIcon plist key -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] ANN: py2app 0.1.7
This announcement is available in HTML at: http://bob.pythonmac.org/archives/2004/12/30/ann-py2app-017/ `py2app`_ is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to `py2exe`_, that builds Mac OS X applications from Python scripts, extensions, and related data files. It tries very hard to include all dependencies it can find so that your application can be distributed standalone, as Mac OS X applications should be. `py2app`_ 0.1.7 is included in the installer for `PyObjC`_ 1.2. If you have installed `PyObjC`_ 1.2, then you already have `py2app`_ 0.1.7 installed. Download and related links are here: http://undefined.org/python/#py2app `py2app`_ 0.1.7 is a bug fix release: * The ``bdist_mpkg`` script will now set up sys.path properly, for setup scripts that require local imports. * ``bdist_mpkg`` will now correctly accept ``ReadMe``, ``License``, ``Welcome``, and ``background`` files by parameter. * ``bdist_mpkg`` can now display a custom background again (0.1.6 broke this). * ``bdist_mpkg`` now accepts a ``build-base=`` argument, to put build files in an alternate location. * ``py2app`` will now accept main scripts with a ``.pyw`` extension. * ``py2app``'s not_stdlib_filter will now ignore a ``site-python`` directory as well as ``site-packages``. * ``py2app``'s plugin bundle template no longer displays GUI dialogs by default, but still links to ``AppKit``. * ``py2app`` now ensures that the directory of the main script is now added to ``sys.path`` when scanning modules. * The ``py2app`` build command has been refactored such that it would be easier to change its behavior by subclassing. * ``py2app`` alias bundles can now cope with editors that do atomic saves (write new file, swap names with existing file). * ``macholib`` now has minimal support for fat binaries. It still assumes big endian and will not make any changes to a little endian header. * Add a warning message when using the ``install`` command rather than installing from a package. * New ``simple/structured`` example that shows how you could package an application that is organized into several folders. * New ``PyObjC/pbplugin`` Xcode Plug-In example. Since I have been slacking and the last announcement was for 0.1.4, here are the changes for the soft-launched releases 0.1.5 and 0.1.6: `py2app`_ 0.1.6 was a major feature enhancements release: * ``py2applet`` and ``bdist_mpkg`` scripts have been moved to Python modules so that the functionality can be shared with the tools. * Generic graph-related functionality from ``py2app`` was moved to ``altgraph.ObjectGraph`` and ``altgraph.GraphUtil``. * ``bdist_mpkg`` now outputs more specific plist requirements (for future compatibility). * ``py2app`` can now create plugin bundles (MH_BUNDLE) as well as executables. * New recipe for supporting extensions built with `sip`_, such as `PyQt`_. Note that due to the way that `sip`_ works, when one sip-based extension is used, *all* sip-based extensions are included in your application. In practice, this means anything provided by `Riverbank`_, I don't think anyone else uses `sip`_ (publicly). * New recipe for `PyOpenGL`_. This is very naive and simply includes the whole thing, rather than trying to monkeypatch their brain-dead version acquisition routine in ``__init__``. * Bootstrap now sets ``ARGVZERO`` and ``EXECUTABLEPATH`` environment variables, corresponding to the ``argv[0]`` and the ``_NSGetExecutablePath(...)`` that the bundle saw. This is only really useful if you need to relaunch your own application. * More correct ``dyld`` search behavior. * Refactored ``macholib`` to use ``altgraph``, can now generate `GraphViz`_ graphs and more complex analysis of dependencies can be done. * ``macholib`` was refactored to be easier to maintain, and the structure handling has been optimized a bit. * The few tests that there are were refactored in `py.test`_ style. * New `PyQt`_ example. * New `PyOpenGL`_ example. `py2app`_ 0.1.5 was a major feature enhancements release: * Added a ``bdist_mpkg`` distutils extension, for creating Installer an metapackage from any distutils script. - Includes PackageInstaller tool - bdist_mpkg script - setup.py enhancements to support bdist_mpkg functionality * Added a ``PackageInstaller`` tool, a droplet that performs the same function as the ``bdist_mpkg`` script. * Create a custom ``bdist_mpkg`` subclass for `py2app`_'s setup script. * Source package now includes `PJE`_'s `setuptools`_ extension to distutils. * Added lots of metadata to the setup script. * ``py2app.modulegraph`` is now a top-level package, ``modulegraph``. * ``py2app.find_modules`` is now ``modulegraph.find_modules``. * Should now correctly handle paths (and application name
Re: [Pythonmac-SIG] ANN: pyobjc-1.2
On Jan 1, 2005, at 9:29 PM, Dethe Elza wrote: I have a couple of questions about pyobjc 1.2. First, can Categories extend classes which are defined in Python? Only if they are a subclass of an Objective-C class. Second, what applications can be extended with plugins? I realize a complete list is unfeasible, but which Apple applications would be a good start. As far as I can tell, Safari requires Netscape-style plugins to extend it, is that wrong? Any application that expects its plugins to be written in Objective-C is fair game, anything else (such as Safari's Netscape-style plugins) is unsupported and probably won't work. The reason for this is that applications that expect plugins to be written in C or C++ are probably going to expect that particular symbols are defined in the plugin, and that is basically impossible to do at runtime and would require some custom compiled C/C++ stub. Objective-C is dynamic enough that this may be done at runtime using a dyld bundle loader hook to define the class while the application is trying to look it up. It is theoretically possible to make this work without requiring a custom stub (b/c macholib could rewrite the symbol table), but I'm not going to write such a monstrosity any time soon unless someone is willing to pay me a lot to do it. I simply just don't have a need for it, and if I did, I would likely just write a custom C/C++ stub. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.2, 1.3
On Jan 1, 2005, at 5:33 PM, [EMAIL PROTECTED] wrote: Update of /cvsroot/python/python/dist/src/Mac/OSX In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv14408 Modified Files: fixapplepython23.py Log Message: Create the wrapper scripts for gcc/g++ too. +SCRIPT="""#!/bin/sh +export MACOSX_DEPLOYMENT_TARGET=10.3 +exec %s "[EMAIL PROTECTED]" This script should check to see if MACOSX_DEPLOYMENT_TARGET is already set. If I have some reason to set MACOSX_DEPLOYMENT_TARGET=10.4 for compilation (say I'm compiling an extension that requires 10.4 features) then I'm going to have some serious problems with this fix. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] New to phython and need an ide tool help....
On Jan 2, 2005, at 12:47 AM, [EMAIL PROTECTED] wrote: However, I need some help to really easily learn Python. Due to typing limitations of my fingers, I could really use a code auto-complete feature in the Macphython IDE am currently using to learn Python with. Anyone up to adding this? I am not looking for anything fancy for now. Just enough to rapidly insert code and not be stumbling with syntax and correct spelling. I did find one tool to do it but its an expensive one for my limited fixed income and its far more powerful then I need for now. The MacPython IDE isn't really maintained, so it's unlikely that this will happen. You may want to try using Xcode, it will do syntax highlighting and completion of Python code. It's not the smartest around, but it doesn't cost anything (assuming you have a copy of Mac OS X 10.3). PyOXIDE might also have code completion, I'm not sure. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] ANN: pyobjc-1.2
On Jan 2, 2005, at 2:13 AM, Dethe Elza wrote: Second, what applications can be extended with plugins? I realize a complete list is unfeasible, but which Apple applications would be a good start. As far as I can tell, Safari requires Netscape-style plugins to extend it, is that wrong? Any application that expects its plugins to be written in Objective-C is fair game, anything else (such as Safari's Netscape-style plugins) is unsupported and probably won't work. This is also what I expect, but how do I know which applications expect plugins at all? Can I write a plugin for Mail.app? For iCal? What are the rules? If this is in the FAQ somewhere, I haven't seen it, but feel free to tell me to RTFM if it is. You'll have to RTFM on a per-application basis. This doesn't have much to do with PyObjC. As far as I know, Mail will take plugins if you set a certain plist key, and iCal will not. Certain kinds of plugins will get loaded into ANY Carbon or Cocoa application, but I definitely don't think you should do this with a py2app-built plugin because it will probably break applications that use their own copy of Python... so I'm not going to say any more about that. I'm also curious how pyject works with this (if its related at all). Can you give an example of how pyject would be used? pyject <http://svn.red-bean.com/bob/pyject/trunk/> works with this by starting a new thread in an arbitrary pid that loads some plugin using mach_inject. The intended use is to load a py2app-built plugin, which will run whatever module level code is in your main script. I wouldn't recommend it for production use, but it could be used for a lot of interesting things from a software developer's perspective. Again, it's mostly only useful if your application is Objective-C, since there isn't too much you can do with Python in a Carbon application that doesn't expect it (without some deep hacking, anyway). Carbon and Cocoa can play nicely together, so you could do something like load a PyInterpreter into iTunes with a UI that works, but you'd have to be really ambitious to make it actually cause iTunes to do anything differently. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] ANN: pyobjc-1.2
On Jan 2, 2005, at 2:50 PM, Dethe Elza wrote: pyject <http://svn.red-bean.com/bob/pyject/trunk/> works with this by starting a new thread in an arbitrary pid that loads some plugin using mach_inject. The intended use is to load a py2app-built plugin, which will run whatever module level code is in your main script. I wouldn't recommend it for production use, but it could be used for a lot of interesting things from a software developer's perspective. What would be an example use? If you can't immediately think of anything, you probably don't have a use for it :) As it is largely undocumented, has no official release, is quite "evil", and I have no spare time to support it.. I'm not going to encourage its use. If you have a use for it, it's there, but that's about as far as I'm willing to go right now. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.2, 1.3
On Jan 2, 2005, at 4:28 PM, Jack Jansen wrote: On 2-jan-05, at 4:40, Bob Ippolito wrote: +SCRIPT="""#!/bin/sh +export MACOSX_DEPLOYMENT_TARGET=10.3 +exec %s "[EMAIL PROTECTED]" This script should check to see if MACOSX_DEPLOYMENT_TARGET is already set. If I have some reason to set MACOSX_DEPLOYMENT_TARGET=10.4 for compilation (say I'm compiling an extension that requires 10.4 features) then I'm going to have some serious problems with this fix. I was going to do that, but then I thought it didn't make any sense, because this script is *only* used in the context of Apple-provided Python 2.3. And setting MACOSX_DEPLOYMENT_TARGET to anything other than 10.3 (be it lower or higher) while compiling an extension for Apple's 2.3 is going to produce disappointing results anyway. But, if I've missed a use case, please enlighten me. You're right, of course. I had realized that I was commenting on the fixpython script after I had replied, but my concern is still applicable to whatever solution is used for Python 2.4.1. Anything lower than 10.3 is of course an error, in either case. -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Darwin's realloc(...) implementation never shrinks allocations
Quite a few notable places in the Python sources expect realloc(...) to relinquish some memory if the requested size is smaller than the currently allocated size. This is definitely not true on Darwin, and possibly other platforms. I have tested this on OpenBSD and Linux, and the implementations on these platforms do appear to relinquish memory, but I didn't read the implementation. I haven't been able to find any documentation that states that realloc should make this guarantee, but I figure Darwin does this as an "optimization" and because Darwin probably can't resize mmap'ed memory (at least it can't from Python, but this probably means it doesn't have this capability at all). It is possible to "fix" this for Darwin, because you can ask the default malloc zone how big a particular allocation is, and how big an allocation of a given size will actually be (see: ). The obvious place to put this would be PyObject_Realloc, because this is at least called by _PyString_Resize (which will fix <http://python.org/sf/1092502>). Should I write up a patch that "fixes" this? I guess the best thing to do would be to determine whether the fix should be used at runtime, by allocating a meg or so, resizing it to 1 byte, and see if the size of the allocation changes. If the size of the allocation does change, then the system realloc can be trusted to do what Python expects it to do, otherwise realloc should be done "cleanly" by allocating a new block (returning the original on failure, because it's good enough and some places in Python seem to expect that shrink will never fail), memcpy, free, return new block. I wrote up a small hack that does this realloc indirection to CVS trunk, and it doesn't seem to cause any measurable difference in pystone performance. Note that all versions of Darwin that I've looked at (6.x, 7.x, and 8.0b1 corresponding to publicly available WWDC 2004 Tiger code) have this "issue", but it might go away by Mac OS X 10.4 or some later release. This URL points to the sf bug and Darwin 7.7's realloc(...) implementation: http://bob.pythonmac.org/archives/2005/01/01/realloc-doesnt/ -bob ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations
On Jan 3, 2005, at 12:13 AM, Tim Peters wrote: [Bob Ippolito] Quite a few notable places in the Python sources expect realloc(...) to relinquish some memory if the requested size is smaller than the currently allocated size. I don't know what "relinquish some memory" means. If it means something like "returns memory to the OS, so that the reported process size shrinks", then no, nothing in Python ever assumes that. That's simply because "returns memory to the OS" and "process size" aren't concepts in the C standard, and so nothing can be said about them in general -- not in theory, and neither in practice, because platforms (OS+libc combos) vary so widely in behavior here. As a pragmatic matter, I *expect* that a production-quality realloc() implementation will at least be able to reuse released memory, provided that the amount released is at least half the amount originally malloc()'ed (and, e.g., reasonable buddy systems may not be able to do better than that). This is what I meant by relinquish (c/o merriam-webster): a : to stop holding physically : RELEASE b : to give over possession or control of : YIELD Your expectation is not correct for Darwin's memory allocation scheme. It seems that Darwin creates allocations of immutable size. The only way ANY part of an allocation will ever be used by ANYTHING else is if free() is called with that allocation. free() can be called either explicitly, or implicitly by calling realloc() with a size larger than the size of the allocation. In that case, it will create a new allocation of at least the requested size, copy the contents of the original allocation into the new allocation (probably with copy-on-write pages if it's large enough, so it might be cheap), and free() the allocation. In the case where realloc() specifies a size that is not greater than the allocation's size, it will simply return the given allocation and cause no side-effects whatsoever. Was this a good decision? Probably not! However, it is our (in the "I know you use Windows but I am not the only one that uses Mac OS X" sense) problem so long as Darwin is a supported platform, because it is highly unlikely that Apple will backport any "fix" to the allocator unless we can prove it has some security implications in software shipped with their OS. I attempted to look for some easy ones by performing a quick audit of Apache, OpenSSH, and OpenSSL. Unfortunately, their developers did not share your expectation. I found one sprintf-like routine in Apache that could be affected by this behavior, and one instance of immutable string creation in Apple's CoreFoundation CFString implementation, but I have yet to find an easy way to exploit this behavior from the outside. I should probably be looking at PHP and Perl instead ;) but I figure Darwin does this as an "optimization" and because Darwin probably can't resize mmap'ed memory (at least it can't from Python, but this probably means it doesn't have this capability at all). It is possible to "fix" this for Darwin, I don't understand what's "broken". Small objects go thru Python's own allocator, which has its own realloc policies and its own peculiarities (chiefly that pymalloc never free()s any memory allocated for small objects). What's broken is that there are several places in Python that seem to assume that you can allocate a large chunk of memory, and make it smaller in some meaningful way with realloc(...). This is not true with Darwin. You are right about small objects. They don't matter because they're small, and because they're handled by Python's allocator. because you can ask the default malloc zone how big a particular allocation is, and how big an allocation of a given size will actually be (see: ). The obvious place to put this would be PyObject_Realloc, because this is at least called by _PyString_Resize (which will fix <http://python.org/sf/1092502>). The diagnosis in the bug report seems to leave it pointing at socket.py's _fileobject.read(), although I suspect the real cause is in socketmodule.c's sock_recv(). We've had other reports of various problems when people pass absurdly large values to socket recv(). A better fix here would probably amount to rewriting sock_recv() to refuse to pass enormous numbers to the platform recv() (it appears that many platform recv() implementations simply don't expect a recv() argument to be much bigger than the native network buffer size, and screw up when that's not so). You are correct. The real cause is in sock_recv(), and/or _PyString_Resize(), depending on how you look at it. Note that all versions of Darwin that I've looked at (6.x, 7.x, and 8.0b1 corresponding to publicly available WWDC 2004 Tiger code)
[Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations
On Jan 3, 2005, at 2:16 AM, Tim Peters wrote: [Bob Ippolito] ... Your expectation is not correct for Darwin's memory allocation scheme. It seems that Darwin creates allocations of immutable size. The only way ANY part of an allocation will ever be used by ANYTHING else is if free() is called with that allocation. Ya, I understood that. My conclusion was that Darwin's realloc() implementation isn't production-quality. So it goes. Whatever that means. free() can be called either explicitly, or implicitly by calling realloc() with a size larger than the size of the allocation. In that case, it will create a new allocation of at least the requested size, copy the contents of the original allocation into the new allocation (probably with copy-on-write pages if it's large enough, so it might be cheap), and free() the allocation. Really? Another near-universal "quality of implementation" expectation is that a growing realloc() will strive to extend in-place. Like realloc(malloc(100), 101). For example, the theoretical guarantee that one-at-a-time list.append() has amortized linear time doesn't depend on that, but pragmatically it's greatly helped by a reasonable growing realloc() implementation. I said that it created allocations of fixed size, not that it created allocations of exactly the size you asked it to. Yes, it will extend in-place for many cases, including the given. In the case where realloc() specifies a size that is not greater than the allocation's size, it will simply return the given allocation and cause no side- effects whatsoever. Was this a good decision? Probably not! Sounds more like a bug (or two) to me than "a decision", but I don't know. You said yourself that it is standards compliant ;) I have filed it as a bug, but it is probably unlikely to be backported to current versions of Mac OS X unless a case can be made that it is indeed a security flaw. However, it is our (in the "I know you use Windows but I am not the only one that uses Mac OS X sense) problem so long as Darwin is a supported platform, because it is highly unlikely that Apple will backport any "fix" to the allocator unless we can prove it has some security implications in software shipped with their OS. ... Is there any known case where Python performs poorly on this OS, for this reason, other than the "pass giant numbers to recv() and then shrink the string because we didn't get anywhere near that many bytes" case? Claiming rampant performance problems should require evidence too . Known case? No. Do I want to search Python application-space to find one? No. Presumably this can happen at other places (including third party extensions), so a better place to do this might be _PyString_Resize(). list_resize() is another reasonable place to put this. I'm sure there are other places that use realloc() too, and the majority of them do this through obmalloc. So maybe instead of trying to track down all the places where this can manifest, we should just "gunk up" Python and patch PyObject_Realloc()? There is no "choke point" for allocations in Python -- some places call the system realloc() directly. Maybe the latter matter on Darwin too, but maybe they don't. The scope of this hack spreads if they do. I have no idea how often realloc() is called directly by 3rd-party extension modules. It's called directly a lot in Zope's C code, but AFAICT only to grow vectors, never to shrink them. In the case of Python, "some places" means "nowhere relevant". Four standard library extension modules relevant to the platform use realloc directly: _sre Uses realloc only to grow buffers. cPickle Uses realloc only to grow buffers. cStringIO Uses realloc only to grow buffers. regexpr: Uses realloc only to grow buffers. If Zope doesn't use the allocator that Python gives it, then it can deal with its own problems. I would expect most extensions to use Python's allocator. Since we are both pretty confident that other allocators aren't like Darwin, this "gunk" can be #ifdef'ed to the __APPLE__ case. #ifdef's are a last resort: they almost never go away, so they complicate the code forever after, and typically stick around for years even after the platform problems they intended to address have been fixed. For obvious reasons, they're also an endless source of platform-specific bugs. They're also the only good way to deal with platform-specific inconsistencies. In this specific case, it's not even possible to determine if a particular allocator implementation is stupid or not without at least using a platform-allocator-specific function to query the size reserved by a given allocation. Note that pymalloc already does a memcpy+free when in PyObject_Realloc(p, n) p was obtaine
