Mercurial install after MacPython.app, Leopard, Google App Engine

[Phil Rand]

Hi all,

I recently upgraded to Leopard, and today I had trouble upgrading Mercurial.

I've got it working now, but don't have a compete explanation.  Here's
what I found and did (all done interactively, without taking notes, so
the details are rapidly slipping away).

I decided to rename /opt/local to /opt/local.00, create a new
/opt/local, and reinstall MacPorts.  That went nicely, but "sudo port
install mercurial" ran into trouble with the python extensions,
py25-zlib, py25-hashlib, and py25-bz2.

I found "Library/Frameworks/Python.framework/Versions/2.5/bin" at the
beginning of my PATH environment variable.  I tracked that down to my
~/.profile file, removed that, and made sure /opt/local/bin was first
in my PATH.

I found MacPython2.5.app in my Applications folder, and renamed it.

I found symbolic links from /usr/local/bin for python, python2.5, and
related commands, pointing to files in
/Library/Frameworks/Python.framework/Versions/2.5/bin.

I had installed an early version of the Google App Engine prior to
Leopard, and wonder if it might have done some of this.

I uninstalled all the deps for mercurial, and installed python25.  It
did not install /opt/local/bin/python, only /opt/local/bin/python2.5.
After that the python extensions py25-zlib, py25-hashlib, py25-bz2
woudn't install until I created a symbolic link:  cd /opt/local/bin;
ln -s python2.5 python

Is it expected for the python25 port NOT to create
/opt/local/bin/python, but only /opt/local/bin/python2.5?  Is there a
better workaround than my symbolic link?

And I guess another lesson here is that installing a package in
multiple locations can lead to confusion.  No surprise there.

What is the MacPorts strategy to deal with a situation where OSX comes
with some version of a package like python for which people will want
to install add-ons?  I'm assuming it is "Install our own copy in the
usual locations in /opt/local, and depend on PATH and other
environment variables to keep the MacPorts version from fighting with
the OSX version, right?  It's not very clean, but I'm sure we don't
want MacPorts modifying OSX-supplied components.

Thanks for reading this far.  I hope my example might save somebody
else some frustration.

-- 
Phil Rand
philrand at pobox.com

 ,