[Pythonmac-SIG] MachoPython 2.2.2 build question

Russell E Owen owen@astro.washington.edu
Sat, 9 Nov 2002 10:41:56 -0800


>On donderdag, nov 7, 2002, at 19:55 Europe/Amsterdam, Russell E Owen wrote:
>>- First try: unpack 2.2.2 and:
>>./configure --enable-framework
>>make
>>sudo make install
>>
>>This results in a Library/Frameworks/Python.framework/Versions/2.2
>>which contains, among other things: bin/python
>>(Note that the contents of 2.2 are totally unlike those of 2.3, and 
>>that no Current directory was created.)
>
>This sounds like a bug. Could you file a report at sourceforge so 
>that I get to look at it before (if ever) 2.2.3 comes out?
>
>As a workaround, go to /Library/Frameworks/Python.framework/Versions 
>and type "ln -s 2.2 Current".

This was entirely my fault. I mishandled the framework build of 
2.2.2. Thanks to all the help I got that figured out and the build 
works correctly. (I also removed the debug statements that you 
mentioned and rebuilt again and that worked perfectly.)

Regarding an earlier post about trouble with PYTHONSTARTUP, I have 
more info on it. Defining the environment variable in 
~/.MacOSX/environment.plist does work fine for plain "python" 
(despite my earlier report to the contrary); however it still does 
*NOT* work for pythonw (it shows up in os.environ but the file is not 
actually run when pythonw starts up).

What I did wrong the first time was use ~ in my definition of the 
environment variable. I'd forgotten that ~ is not expanded when it 
appears in ~/.MacOSX/environment.plist. (I've also posted a page 
about using this file to define environment variables for MacOS X 
native applications, and have linked to it from my "how to build 
Python 2.2.2" page).

Just for fun, I presently have both a PYTHONSTARTUP file defined in 
~/.MacOSX/environment.plist (which does nothing more than print 
"running startup", since it's not run by pythonw) and also a 
"sitecustomize.py" on my PYTHONPATH (which works fine; it does the 
actual setup and also prints a different diagnostic statement). That 
way I can easily test variations, new versions of Python, etc.

I've noticed a quirk that may be relevant: pythonw starts up slightly 
differently than python -- it reports the same version number, but it 
prints out slightly different help text and the sitecustomize.py's 
print statement shows up at a different point during startup. If 
there's interest, I'll post the full output of each startup here (I'm 
not at work and so cannot do it right now).

-- Russell