[Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?

[Ned Deily]

In article <rowen-81D53B.15565607042011 at news.gmane.org>,
 "Russell E. Owen" <rowen at uw.edu> wrote:
> I'm surprised you can't find it. I've always had it saved on some 
> obvious place. But I agree that hacking the file is ugly -- it least it 
> could ask.

Well, as I noted, the installer actually does warn you and give you the 
option to not hack it, if you follow through and click on the Customize 
button.  Python 3 installers come with that option deselected by 
default, by the way, and, yes, the hack is ugly.  I hope we can 
something a bit more elegant by the time 3.3 releases.

> Other gripes about the installer:
> - It names the version explicitly instead of using the Current symlink 
> (/Libraries/Packages/Python.Package/Versions/Current).

Sorry, I don't understand that.

> - It hacks the file even if doesn't need to (e.g. if Current is already 
> on the $PATH then the new python will be found; I think that would be 
> easy to check).

Oh, I see.  You meant with regards to how $PATH is set up.  One problem 
with that now is that it is quite reasonable to have both a Python 2 and 
a Python 3 version "active" at the same time so the "Current" symlink is 
of less value than it once was.  In fact, the Python 3 installers 
deliberately do not alter "Current".  AFAIK, there is no other problem 
with having both a Python 2 bin and Python 3 bin directory on $PATH 
simultaneously as there is no overlap between the standard file names: 
all of the Python 3 bin files have a "3" included in them.  (The one 
exception to that at the moment is "2to3" which is a bit of a special 
case but there are versioned names, 2to3-3.2 and 2to3-2.7, if it is 
necessary to distinguish them.)

A case could be made I guess for using a different framework name, say 
Python3, so that there could be separate Current values for 2 and 3.  
But, I think there are bigger opportunities to rethink the installation 
process and layouts for Python 3.3.

> - It adds a bunch of links to /usr/local/bin even though that is 
> redundant with putting Python's bin directory on the $PATH. This makes 
> it a headache to switch Python versions -- something developers often 
> need to do when testing compatibility.

The installation of those links can also be disabled in the installer's 
Customize panel.  But, yes, I've come around to the thinking that those 
links cause more trouble that they are worth, especially since the 
framework bin directory is where Distutils-installed script files get 
installed.  Another potential change for 3.3.

> That said, they're minor annoyances and I've not come forward to fix any 
> of them. And the resulting python works nicely.

I guess that's the most important part :)

-- 
 Ned Deily,
 nad at acm.org