Re: [Pythonmac-SIG] Opening an app from another app under different OS X versions
On 24 Jan, 2007, at 18:44, Dethe Elza wrote: Also, paths are different on internationalized versions of OS X. The aren't AFAIK. The finder is localized and shows different folder names if you run in another language (that's why there are .localized turds in several directories). Windows is the OS where directory names actually do change depending on the language you install it in. The OSX implementation actually makes it possible to have several accounts with different languages and have them all see their localized version of folder names. --Dethe You need to lay out the user interface components visually, by hand, with total control over where they go. Automated LayoutManagers don’t cut it. A corollary of this is that you can’t move a UI layout from one platform to another and have the computer make everything fit. Computers don’t lay out interfaces by themselves any better than they can translate French to English by themselves. -- Jens Alfke +1 smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Question about setup.py build
On 24 Jan, 2007, at 23:26, Bob Ippolito wrote: On 1/24/07, Daniel Lord [EMAIL PROTECTED] wrote: I admit to being a novice at this yet, but I couldn't find anything relevant to this issue on-line: I am trying to build a version of pysqlite that works with sqllite3 : 1. Apple's installed version doesn't work with the latest so I reinstalled 2. sqllite3 won't build shared libs for universal binaries (typical of a lot of linux/UNIX build since the developers never have that problem except on OS X) Why would you want shared libs anyway? I'm pretty sure the Mac build script that comes with Python 2.5 (Mac/BuildScript/build-installer.py) will automatically download SQLite and compile it universally as a static lib. Take a look in there. It does, the sqlite module in the binary distribution for python 2.5 links with our own copy of sqlite because the distribution also works on 10.3 and Apple didn't ship sqlite with that release. I'm also pretty sure that I didn't anything that would make it impossible to build a univeral dynamic library, I use a static lib because that's more convenient. The only reason to use a dylib when building extensions is when you have multiple extensions that link to the same library and share access (that's why the bundles ncurses in py2.5 is a shared library). 3. so I built Intel-only but 4. pysqlite keeps trying to build a universal build (CFLAGS=-O -g - isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc; etc. etc.) with python setup.py build 5. But nowhere in the setup.py or setup.cfg is that set. I explicitly unset CFLAGS and LDFLAGS to ensure it wasn't coming from there. So where is it being set? By the Python build? Where? I jsut need a little pointer or two and I'll do the rest. Thanks. The same place that everything else that distutils knows about is coming from, the Makefile in your Python library that was created when Python was built: lib/python2.4/config/Makefile Barring bug adding '-arch', 'i386' to the compile and link flags for an extension should do the right thing (that is, distutils will recoginze these flags and remove the default -arch flags when the user specified a specific architecture). Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Opening an app from another app under different OSX versions
On 24 Jan, 2007, at 23:29, Bob Ippolito wrote: On 1/24/07, David Woods [EMAIL PROTECTED] wrote: Adding the path didn't help. Calling open -a TransanaHelp.app from the command line finds the app, and adding the full path makes is start a bit faster. But when the same call is made from within my bundled Python program (regardless of whether the path is included), I see the following in the console: 'import site' failed; use -v for traceback Traceback (most recent call last): File /Applications/Transana_2/TransanaHelp.app/Contents/MacOS/ TransanaHelp, line 3, in ? import sys, os ImportError: No module named os So it seems, if I'm interpreting this right, like Python's not able to find its own modules under this particular scenario. Line 3 of TransanaHelp.py, by the way, is not the import statement shown here. That line 3 is of some internal Python routine that's not part of my code. I had a problem like this when first moving from distutils-based setup files to setuptools-based setup files. Getting the latest version of py2app may help. --Dethe Upgrading to py2app 0.3.5 had absolutely no effect. It's *probably* because py2app sets a lot of environment variables that can effect child Python interpreters... Try clearing out any PY* environment variables sometime early in your script. And please try to build a small application that reproduces the problem when this doesn't work out. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Opening an app from another app under different OS X versions
On 25-Jan-07, at 12:08 AM, Ronald Oussoren wrote: On 24 Jan, 2007, at 18:44, Dethe Elza wrote: Also, paths are different on internationalized versions of OS X. The aren't AFAIK. The finder is localized and shows different folder names if you run in another language (that's why there are .localized turds in several directories). Windows is the OS where directory names actually do change depending on the language you install it in. The OSX implementation actually makes it possible to have several accounts with different languages and have them all see their localized version of folder names. Cool, I didn't know that. I'm pretty sure older versions of Mac OS (pre-OS X) *did* work that way--you had to use symbolic constants to refer to known folders and not count on the exact file paths. That said, using fully-qualified paths can still be fragile, since users may move things around when you least expect it. --Dethe There's a little bit of God in every truck driver and a little bit of truck driver in every God. -- Blayne Horner ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Opening an app from another app under different OSX versions -- SOLVED
On 1/24/07, David Woods [EMAIL PROTECTED] wrote: Adding the path didn't help. Calling open -a TransanaHelp.app from the command line finds the app, and adding the full path makes is start a bit faster. But when the same call is made from within my bundled Python program (regardless of whether the path is included), I see the following in the console: 'import site' failed; use -v for traceback Traceback (most recent call last): File /Applications/Transana_2/TransanaHelp.app/Contents/MacOS/ TransanaHelp, line 3, in ? import sys, os ImportError: No module named os So it seems, if I'm interpreting this right, like Python's not able to find its own modules under this particular scenario. Line 3 of TransanaHelp.py, by the way, is not the import statement shown here. That line 3 is of some internal Python routine that's not part of my code. I had a problem like this when first moving from distutils-based setup files to setuptools-based setup files. Getting the latest version of py2app may help. --Dethe Upgrading to py2app 0.3.5 had absolutely no effect. It's *probably* because py2app sets a lot of environment variables that can effect child Python interpreters... Try clearing out any PY* environment variables sometime early in your script. -bob Bob, That was indeed the source of the problem. I now delete the PYTHONHOME, PYTHONPATH, and PYTHONEXECUTABLE environment variables before the os.system() call and the Help application shows up as it should. Am I likely to see side-effects from deleting these environment variables? Should I restore them to their original values after the Help call has been made? Thanks a ton for your help. I *NEVER* would've figure this one out. David ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Opening an app from another app under different OSX versions -- SOLVED
On 1/25/07, David Woods [EMAIL PROTECTED] wrote: On 1/24/07, David Woods [EMAIL PROTECTED] wrote: Adding the path didn't help. Calling open -a TransanaHelp.app from the command line finds the app, and adding the full path makes is start a bit faster. But when the same call is made from within my bundled Python program (regardless of whether the path is included), I see the following in the console: 'import site' failed; use -v for traceback Traceback (most recent call last): File /Applications/Transana_2/TransanaHelp.app/Contents/MacOS/ TransanaHelp, line 3, in ? import sys, os ImportError: No module named os So it seems, if I'm interpreting this right, like Python's not able to find its own modules under this particular scenario. Line 3 of TransanaHelp.py, by the way, is not the import statement shown here. That line 3 is of some internal Python routine that's not part of my code. I had a problem like this when first moving from distutils-based setup files to setuptools-based setup files. Getting the latest version of py2app may help. --Dethe Upgrading to py2app 0.3.5 had absolutely no effect. It's *probably* because py2app sets a lot of environment variables that can effect child Python interpreters... Try clearing out any PY* environment variables sometime early in your script. -bob Bob, That was indeed the source of the problem. I now delete the PYTHONHOME, PYTHONPATH, and PYTHONEXECUTABLE environment variables before the os.system() call and the Help application shows up as it should. Am I likely to see side-effects from deleting these environment variables? Should I restore them to their original values after the Help call has been made? No, there will not be side-effects. Those variables are used by py2app's bootstrap executable to communicate with the Python interpreter on startup and that's it. Thanks a ton for your help. I *NEVER* would've figure this one out. It's certainly not obvious. I only knew what it was because I wrote py2app ;) -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
