The file Mac/README in Python 2.6b3 says:

Installing in another place, for instance $HOME/Library/Frameworks if 
you have no admin privileges on your machine, has only been tested very 
lightly. This can be done by configuring with --enable-
framework=$HOME/Library/Frameworks. The other two directories, 
"/Applications/MacPython-2.6" and /usr/local/bin, will then also be 
deposited in $HOME. This is sub-optimal for the unix tools, which you 
would want in $HOME/bin, but there is no easy way to fix this right
now.


In reality, the framework is installed in the directory given on the 
command line, but the installer then wants to write the app to 
/Applications/MacPython-2.6 and crashes due to lack of write permission:

DYLD_FRAMEWORK_PATH=/shared_scratch/Python-2.6b3:  ../python.exe 
./scripts/Buil\
dApplet.py \
        --destroot "" \
        --
python=/shared_scratch/Library/Frameworks/Python.framework/Versions/2\
.6/Resources/Python.app/Contents/MacOS/Python`test -f 
"/shared_scratch/Library/\
Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/M
acOS/Py\
thon-32" && echo "-32"`  \
        --output "/Applications/Python 2.6/Build Applet.app" \
        ./scripts/BuildApplet.py
kCGErrorRangeCheck : Window Server communications from outside of 
session allow\
ed for root and console user only
./scripts/BuildApplet.py:34: DeprecationWarning: catching of string 
exceptions \
is deprecated
  except buildtools.BuildError, detail:
Traceback (most recent call last):
  File "./scripts/BuildApplet.py", line 149, in <module>
    main()
  File "./scripts/BuildApplet.py", line 33, in main
    buildapplet()
  File "./scripts/BuildApplet.py", line 116, in buildapplet
    progress=verbose, destroot=destroot)
  File "/Volumes/User data/Scratch/Python-2.6b3/Lib/plat-
mac/buildtools.py", li\
ne 115, in process
    copy_codefragment, raw, others, filename, destroot)
  File "/Volumes/User data/Scratch/Python-2.6b3/Lib/plat-
mac/buildtools.py", li\
ne 140, in process_common
    is_update, raw, others, filename, destroot)
  File "/Volumes/User data/Scratch/Python-2.6b3/Lib/plat-
mac/buildtools.py", li\
ne 327, in process_common_macho
    builder.build()
  File "/Volumes/User data/Scratch/Python-2.6b3/Lib/plat-
mac/bundlebuilder.py",\
 line 147, in build
    os.mkdir(builddir)
OSError: [Errno 13] Permission denied: '/Applications/Python 2.6'
make[1]: *** [install_BuildApplet] Error 1
make: *** [frameworkinstallapps] Error 2

The same issue is present in 2.4 and 2.5 as well as 3.0 so I'm updating
this issue accordingly (haven't tried 2.7 or 3.1).  I've been working
around this issue with some success and will be posting patches shortly.

Actually this seems to be fixed in 3.0.1 - yay!

Attached a fix for release26-maint branch.

I've tested this as follows:

./configure --enable-toolbox-glue --enable-universalsdk
--enable-framework=/tmp/python-2.6-maint-install/Library/Framework
--prefix=/tmp/python-2.6-maint-install && make -j3 && make frameworkinstall

I have not tested this with the default install paths.

Patches for 2.5 and 2.4 coming up.

Julian: patches for 2.4 and 2.5 will not be accepted, both releases are in 
"critical security fixes only" mode.

I had a hunch that might be the case.  I'm still planning to upload them
here for the benefit of others who, like me, have to maintain those
versions as framework installs.  Is that OK?

Uploading a patch is fine, my comment was just a warning that your patch 
won't be applied in the repository (at least not for 2.4 and 2.5).

I will look at your patch for 2.6 in the near future. 

Are you sure that the issue is fixed in 3.x? AFAIK that would be 
completely accidental, I'm pretty sure I haven't changed anything that 
would affect this.

I was a bit surprised myself but I've just double-checked and it seems
to work fine.  I started with a freshly unpacked 3.0.1 tarball and used
the following command:

./configure --enable-toolbox-glue --enable-universalsdk
--enable-framework=/tmp/python-3.0.1-install/Library/Framework
--prefix=/tmp/python-3.0.1-install && make -j3 && make fullinstall

That went through OK, everything seems to be in its place and the
interpreter starts up.

I was testing with "make frameworkinstall" earlier, that worked, too.

One question, $PREFIX/bin doesn't have the files without version number
(e.g. it has python3.0 but doesn't have python) even in fullinstall
mode.  Is that intentional?  (The framework's bin directory does have
all files.)  I've seen the same issue in 2.6.

For 3.1 I need to check if the right files get install into the various 
'bin' directories. At the languages summit at PyCon'09 the consensus 
seemed to be that the command-line interpreter for Python 3.x should be 
"python3" and that "python" would always refer to a Python 2.x 
interpreter.

I haven't updated the Mac Makefiles for that yet.

Ah, that makes sense - thanks for clarifying.

And I was mistaken about 2.6, the no-suffix symlinks are there in
$PREFIX/bin so all is good.

Let me know what you think of the patch when you get a chance to look at it.

On second thought, are you sure that's how fullinstall is meant to work?
If I use frameworkinstall I get the following message at the end:

* Note: not installed as 'python'.
* Use 'make fullinstall' to install as 'python'.
* However, 'make fullinstall' is discouraged,
* as it will clobber your Python 2.x installation.

Doesn't that suggest that fullinstall would put the no-suffix symlinks
in place?

In other words, is there a reason that no-suffix links _are_ installed
in the framework bin directory in fullinstall mode, but aren't installed
in $PREFIX/bin?

I'm using Python 2.6.4 on OSX 10.6 and I first used the mv command to rename the original python.framework. Then I was able to install 2.6 as the new python.framework. These are the commands:

rename it:
sudo mv /Library/Frameworks/Python.framework /Library/Frameworks/Python_old.framework

install new python:
./configure --enable-framework --with-framework-name=Python --enable-universalsdk=/ --with-universal-archs=intel

In r80647 (trunk) you can use "configure --enable-framework=$HOME/Library/Frameworks" to get the right situation:

- Framework in ~/Library/Frameworks
- Apps in ~/Applications/Python 2.7
- Command-line tools in ~/bin

I will port this to 3.2 later on, but won't backport to 2.6 and 3.1.

Als committed this for 3.2: r80648.

I believe I applied the patch correctly to my Python-2.6.5.tar.bz2, on my OSX 10.6.3 machine, configured with:
./configure --enable-framework=/Users/amos/triad/trunk/src/python

but "make install" now fails with this error at the end:

ln: /usr/local/bin/python2.6: Permission denied
ln: /usr/local/bin/pythonw2.6: Permission denied
ln: /usr/local/bin/idle2.6: Permission denied
ln: /usr/local/bin/pydoc2.6: Permission denied
ln: /usr/local/bin/python2.6-config: Permission denied
ln: /usr/local/bin/smtpd2.6.py: Permission denied
make[1]: *** [altinstallunixtools] Error 1
make: *** [frameworkaltinstallunixtools] Error 2


everything else appears ok...


p.s. I tried:
./configure --enable-universalsdk --with-universal-archs=intel --enable-framework=/Users/amos/triad/trunk/src/python
and got the same error.

Installing a framework anywhere but a reasonably standard location doesn't work. You should try to build with "--enable-framework=$SOMEPREFIX/Library/Frameworks". Applications then get installed in "$SOMEPREFIX/Applications" and command-line tools in "$SOMEPREFIX/bin". When SOMEPREFIX is /Library or /System/Library items get installed in the usual location (but don't install into /System/Library unless you are Apple).

Supporting an arbitrary framework prefix would require a clear definition on what to do with Application bundles and command-line tools and I don't have enough of a need for that to start thinking about that.