🌐 Mailman 3 February 2010 - Pythonmac-SIG - python.org

setting the default pathon path
by Norman Khine Feb. 22, 2010

Feb. 22, 2010

hello, on my 10.6.2 i have compiled python 2.6.4 with the following options: $ ./configure --prefix= $HOME/ all works fine, but with one exception. i am trying to build SWFTools and have the following option: $ ./configure --prefix=$HOME PYTHON=$HOME/bin/python but this still finds the default MacPorts python. how do i temporarily change my system so that the default python is $HOME/bin/python i have tried to change the symlink files, i also have in my .profile export PYTHON=$HOME/bin/python:$PYTHON but still does not work: $ which python /opt/local/bin/python what am i missing? thanks norman -- %>>> "".join( [ {'*':'@','^':'.'}.get(c,None) or chr(97+(ord(c)-83)%26) for c in ",adym,*)&uzq^zqf" ] )

2 1

Re: [Pythonmac-SIG] Problems installing Python-2.7a3 on 10.6.2
by Ned Deily Feb. 22, 2010

Feb. 22, 2010

[resending, possibly lost in transit] In article <1266810052.4b81fcc464636(a)astrosun2.astro.cornell.edu>, Tom Loredo <loredo(a)astro.cornell.edu> wrote: > I've tried installing an intel framework universal build of > Py-2.7a3 on Snow Leopard 10.6.2 (i.e., i386 + x86_64). I > used this configure: > > ./configure --prefix=/usr/local/tmp --enable-framework > --with-framework-name=PythonAlpha --enable-universalsdk=/ -- > with-universal-archs=intel [...] > $ which python > /Library/Frameworks/PythonAlpha.framework/Versions/2.7/bin/python > $ python > python: posix_spawn: python: Unknown error: 0 > > I also tried directly executing (with full paths) python, python2.7, > python2, and python-32 in the framework /bin/ directory, all with > the same posix_spawn error. I also tried directly executing those > pythons in /usr/local/tmp, with the same result. > > Any ideas what is preventing the installed versions from running > when the "make'd" version ran fine? Are the non-standard paths > an issue? I don't want to install into the usual /usr/local > paths, since I'm using homebrew to handle /usr/local. Did you try building without using the --with-framework-name option? That's not an option that gets tested much. There should not be a need to use it since different versions of python (2.6, 2.7, 3.1, etc) can co-exist without problem in the same framework. The only potential issue are the unversioned symlinks in /usr/local/bin/, i.e. /usr/local/bin/python will likely get overridden by the most recently installed python 2.x. Either adjust manually or stick to using the versioned symlinks, /usr/local/bin/python2.7 etc. or set your PATH to put the appropriate framework bin directory prior to /usr/local/bin. If it appears that the --with-framework-name option is the problem, please open an issue on the python.org bug tracker. -- Ned Deily nad(a)acm.org -- []

1 0

Re: [Pythonmac-SIG] Problems installing 32-bit Py-2.6.4 framework on 10.6.2
by Ned Deily Feb. 22, 2010

Feb. 22, 2010

[Resending, possibly lost in transit] In article <1266809600.4b81fb00be931(a)astrosun2.astro.cornell.edu>, Tom Loredo <loredo(a)astro.cornell.edu> wrote: > I've been attempting to install a 32-bit version of Python-2.6.4 > on Snow Leopard 10.6.2. I'd like to install it from source (a > 32-bit binary built for 10.3+ is at Python.org). Unfortunately, > I haven't yet figured out a way to get an accessible 32-bit > interpreter built on Snow Leopard. The python.org 2.6.4 is intended for 10.3.9 through 10.6. If you want a 32-bit version, it should suit your needs just fine; there shouldn't be any reason to build it yourself. That said, if you really want to do so: > I have the latest SL Xcode installed, including the 10.4 SDK. > Here's what I've tried. > > Installing with the following configuration to build an > "intel" universal framework: > > $ ./configure --prefix=/usr/local/tmp --enable-framework > --with-universal-archs=intel --enable-universalsdk=/ > > does indeed produce a universal Python with 32-bit (i386) and > 64-bit (x86_64) versions in a bundle, but there is no way to > access the 32 bit executable (the defaults variable that Apple > implemented to provide access to 32-bit 2.6.1 is proprietary and > has no effect on non-Apple installations; the Python.org solution > is to install a separate python-32 executable but this was not > backported to 2.6.4). That will likely be fixed for 2.6.5 which is planned to be released in mid-March. > So I've tried building an "all" universal binary, which should > produce ppc and intel versions of both bit-widths. But that will have the same problem: on 10.6 in the absence of additional application plist information, a 64-bit variant will be given preference. The pre-10.6 4-way universal scheme of producing pythonxx-32 and pythonxx-64 variants also does not work on 10.6 without modification. > $ ./configure --prefix=/usr/local/tmp --with-universal-archs=all > --enable-universalsdk=/ [...] > $ ./configure --prefix=/usr/local/tmp --enable-framework > --with-framework-name=Python32 --enable-universalsdk --with- > universal-archs=32-bit Don't use --enable-universalsdk or --enable-universalsdk=/. Always specify the full path to the appropriate SDK. This error: > (By the way, this produces a config error if I set > MACOSX_DEPLOYMENT_TARGET=10.6, and this error: > #include_next <stdarg.h> are caused by problems when the configure script implicitly selects the wrong value for MACOSX_DEPLOYMENT_TARGET based on the value of --enable-universalsdk. You can avoid these errors by using the explicit SDK path and explicitly setting MACOSX_DEPLOYMENT_TARGET. Appropriate combinations are: export MACOSX_DEPLOYMENT_TARGET=10.3 or export MACOSX_DEPLOYMENT_TARGET=10.4 with .configure --enable-universalsdk=/Developer/SDKs/ MacOSX10.4u.sdk ... export MACOSX_DEPLOYMENT_TARGET=10.5 .configure --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk ... export MACOSX_DEPLOYMENT_TARGET=10.6 .configure --enable-universalsdk=/Developer/SDKs/MacOSX10.6.sdk ... > Also, is there a way to build i386 without building ppc-32? Probably not at the moment. I think the only way on 10.6 is for configure to set only -arch i386 and I don't think there is a way to force that without modifying configure. I'll make sure to check that out before 2.6.5. > PS: What is the role of MACOSX_DEPLOYMENT_TARGET? Was it only a > one-time fix for Leopard installs that should be disregarded post- Leopard? No. MACOSX_DEPLOYMENT_TARGET indicates to gcc and friends what the *minimum* OS X release level that the executable being produced should be able to run on. The python.org installers are intentionally built this way so one installer image and executable will work on a range of operations systems. (In some respects, python's needs are simpler than most GUI applications which is why it can get away with specifying 10.3 while using the 10.4u SDK.) > I ask because NumPy does a check on its value. I don't think > the check is consequential, but to avoid warning messages NumPy > installers are encouraged to set MACOSX_DEPLOYMENT_TARGET=10.6 for > Snow Leopard when installing NumPy. I thought this was "inherited" > from Python itself. I can't speak to what special things NumPy might do but, in general when installing packages with conventional C extension modules, Distutils will ensure that the same values for MACOSX_DEPLOYMENT_TARGET and for the SDK will be used for C compiles as were used when building python itself. -- Ned Deily nad(a)acm.org -- []

1 0

Problems installing 32-bit Py-2.6.4 framework on 10.6.2
by Tom Loredo Feb. 22, 2010

Feb. 22, 2010

Hi folks, I've been attempting to install a 32-bit version of Python-2.6.4 on Snow Leopard 10.6.2. I'd like to install it from source (a 32-bit binary built for 10.3+ is at Python.org). Unfortunately, I haven't yet figured out a way to get an accessible 32-bit interpreter built on Snow Leopard. I have the latest SL Xcode installed, including the 10.4 SDK. Here's what I've tried. Installing with the following configuration to build an "intel" universal framework: $ ./configure --prefix=/usr/local/tmp --enable-framework --with-universal-archs=intel --enable-universalsdk=/ does indeed produce a universal Python with 32-bit (i386) and 64-bit (x86_64) versions in a bundle, but there is no way to access the 32 bit executable (the defaults variable that Apple implemented to provide access to 32-bit 2.6.1 is proprietary and has no effect on non-Apple installations; the Python.org solution is to install a separate python-32 executable but this was not backported to 2.6.4). So I've tried building an "all" universal binary, which should produce ppc and intel versions of both bit-widths. This configure: $ ./configure --prefix=/usr/local/tmp --with-universal-archs=all --enable-universalsdk=/ produces an error during the configure: .. checking for wchar.h... yes checking for wchar_t... yes checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t) See `config.log' for more details. The config.log indicates a problem building ppc64 libraries while linking one of the conftest programs (many "missing required architecture ppc64 in file" messages). So I've tried just building a 32-bit universal framework (I cannot see from the docs any way to build just a 32-bit i386 build): $ ./configure --prefix=/usr/local/tmp --enable-framework --with-framework-name=Python32 --enable-universalsdk --with- universal-archs=32-bit (By the way, this produces a config error if I set MACOSX_DEPLOYMENT_TARGET=10.6, but not if I don't set the target.) In this case "make" immediately fails with errors compiling Modules/python.c: ----- gcc -c -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -fno-common -dynamic - DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c In file included from Include/Python.h:58, from ./Modules/python.c:3: Include/pyport.h:480: warning: struct winsize declared inside parameter list Include/pyport.h:481: warning: struct winsize declared inside parameter list In file included from Include/unicodeobject.h:4, from Include/Python.h:85, from ./Modules/python.c:3: /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error: stdarg.h: No such file or directory In file included from Include/Python.h:58, from ./Modules/python.c:3: Include/pyport.h:480: warning: struct winsize declared inside parameter list Include/pyport.h:481: warning: struct winsize declared inside parameter list In file included from Include/unicodeobject.h:4, from Include/Python.h:85, from ./Modules/python.c:3: /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error: stdarg.h: No such file or directory lipo: can't figure out the architecture type of: /var/folders/Hv/Hvx6V3reHlqGUIlS1r9NS++++TI/-Tmp-//ccbAkLni.out make: *** [Modules/python.o] Error 1 ----- The offending line in the 10.4sdk stdarg.h is: #include_next <stdarg.h> I don't know what this does, and thus have no clue how to diagnose why the stdarg.h it is looking for cannot be found. Any clues? Also, is there a way to build i386 without building ppc-32? Thanks, Tom PS: What is the role of MACOSX_DEPLOYMENT_TARGET? Was it only a one-time fix for Leopard installs that should be disregarded post-Leopard? I ask because NumPy does a check on its value. I don't think the check is consequential, but to avoid warning messages NumPy installers are encouraged to set MACOSX_DEPLOYMENT_TARGET=10.6 for Snow Leopard when installing NumPy. I thought this was "inherited" from Python itself. ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

1 0

Re: [Pythonmac-SIG] Storing path as alias
by has Feb. 21, 2010

Feb. 21, 2010

Tobias Weber wrote: > how do I store an unbreakable alias instead of a POSIX path? > > There's mactypes.Alias in appscript, but it doesn't look serializable. mactypes.Alias doesn't provide flatten/unflatten APIs, but it's just a wrapper around aem.ae.AEDesc, which does. Check their docstrings for more information. > I could use NDAlias via pyobjc and get an NSData out. NSURL has a 'bookmark' feature in 10.6+. HTH has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net

3 2

Storing path as alias
by Tobias Weber Feb. 20, 2010

Feb. 20, 2010

Hi, how do I store an unbreakable alias instead of a POSIX path? There's mactypes.Alias in appscript, but it doesn't look serializable. I could use NDAlias via pyobjc and get an NSData out.

1 0

Crossfold Validation
by Mark Livingstone Feb. 20, 2010

Feb. 20, 2010

Hi Guys, I am looking for suggestions! I am doing some experimentation and want to know if there are any utilities available that will take a file as input, get the num folds and num times, and do the slice and dice file operation ready then for training / testing? I imagine it wouldn't be difficult to write but why reinvent the wheel! Naturally my training / testing will also be on a Mac / Python. Thanks in advance and have a great weekend guys! MarkL

3 2

Re: [Pythonmac-SIG] py2app/PyQt/64-bit/Mach-O
by Kevin Walzer Feb. 18, 2010

Feb. 18, 2010

On 12/7/09 10:13 PM, Nehemiah Dacres wrote: > the solution is to fix the endian bug. you're on intel right? I bet if > you used the new PySide qt python bridge, it wouldn't have this problem. > I bet its talking directly to the c++ runtime Â instead of Â Â It may be an issue with endian-ness, but the same problem has shown up with four-way universal builds of applications using Tkinter (mine) and PyObjC (see http://mail.python.org/pipermail/pythonmac-sig/2008-August/020423.html). It's an issue with macholib and/or py2app, in that they don't seem to be able to handle four-way universal builds. So PySide may not be the answer at all. -- Kevin Walzer Code by Kevin http://www.codebykevin.com

4 10

Installing Cantera
by Jason Norman Feb. 18, 2010

Feb. 18, 2010

I have the same problem - did anyone have an answer?

1 0

build on OS X 10.6.2
by Norman Khine Feb. 17, 2010

Feb. 17, 2010

Hello, I have three python versions, one that came with OS X, one from MacPorts and one which I compiled with: ./configure --prefix=$HOME All works fine, but I don't understand when I change my .profile so that export PYTHON=$HOME/bin/python and try to build for example swftools, swftools only finds the MacPorts python How do I force swftools to use the $HOME/bin/python python version? I tried ./configure --prefix=$HOME PYTHON=$HOME/bin/python but it did not work! Thanks Norman

2 1