Re: [Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?
On 8 Apr, 2011, at 0:56, Russell E. Owen wrote: In article 64461.1302209...@parc.com, Bill Janssen jans...@parc.com wrote: I've got a Snow Leopard buildslave I'm trying to debug. So I thought I'd try Python 2.7 on it. Normally, I advise people to never try to install a different Python on a Mac, as it's too embedded in the OS to do safely, without a great deal of domain knowledge. But here, I figured I could always wipe the disk and start over without too much loss. So I ran the installer, and tried a few things, and it didn't solve my buildbot problems. So I decided to go back to the original System python. But now I find that the installer has put the 2.7 Python on my PATH?!? It does this apparently by hacking ~/.bash_profile. In there, there's a line saying The original version is saved in .bash_profile.pysave a file which doesn't seem to exist. So, why didn't I notice myself checking the checkbox to do this in the first place, and where is my original .bash_profile file? 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. Feel free to file a bug and attach a patch that does this. In any case you can revert by just deleting the extra lines. Other gripes about the installer: - It names the version explicitly instead of using the Current symlink (/Libraries/Packages/Python.Package/Versions/Current). That's intentional, if you install 2.6 with the default settings and 2.7 with the 'update shell profile' section disabled you'd want python 2.6 to be on $PATH while 2.7 shouldn't be. This cannot be done without hardcoding version. - 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). That's a bug, please file a report at bugs.python.org. - 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. This behavior can be disabled when you run the installer. I agree that the default should be to not install files in /usr/local, although we have had users that complained that the 3.x installers didn't do this. BTW. I've talked with Ned about this feature at Pycon and we'd like to move to a python-select command that gives you a command-line tool for managing the path to the current python (simular to gcc-select or xcode-select). That way it should be possible to do away with automaticly patching the shell profile. Ronald ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?
Ronald Oussoren ronaldousso...@mac.com wrote: BTW. I've talked with Ned about this feature at Pycon and we'd like to move to a python-select command that gives you a command-line tool for managing the path to the current python (simular to gcc-select or xcode-select). That way it should be possible to do away with automaticly patching the shell profile. How about a Preference Pane? I could probably remember how to code one up with PyObjC and Python. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?
On 11 Apr, 2011, at 17:13, Bill Janssen wrote: Ronald Oussoren ronaldousso...@mac.com wrote: BTW. I've talked with Ned about this feature at Pycon and we'd like to move to a python-select command that gives you a command-line tool for managing the path to the current python (simular to gcc-select or xcode-select). That way it should be possible to do away with automaticly patching the shell profile. How about a Preference Pane? I could probably remember how to code one up with PyObjC and Python. A preference pane would work as well. It would need to be writting in Objective-C though, both because PyObjC is not part of the stdlib and because PyObjC plugins are not (and cannot be) isolated from each other very well. I'd prefer to have a solution that works from the command-line as well (for power-users and for integration with other tools) Ronald ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?
On 7 Apr, 2011, at 22:48, Bill Janssen wrote:
I've got a Snow Leopard buildslave I'm trying to debug. So I thought
I'd try Python 2.7 on it. Normally, I advise people to never try to
install a different Python on a Mac, as it's too embedded in the OS to
do safely, without a great deal of domain knowledge. But here, I
figured I could always wipe the disk and start over without too much
loss.
So I ran the installer, and tried a few things, and it didn't solve my
buildbot problems. So I decided to go back to the original System
python. But now I find that the installer has put the 2.7 Python on my
PATH?!?
That's correct, there is an option to disable this behavior. This option is on
by default because we had a lot of users that installed Python and then didn't
know how to start python because we don't install files in /usr/bin.
It does this apparently by hacking ~/.bash_profile. In there,
there's a line saying
The original version is saved in .bash_profile.pysave
That's odd, the scriptlet that does the work says ($PR is the path to the
profile):
if [ -f ${PR} ]; then
cp -fp ${PR} ${PR}.pysave
fi
echo ${PR}
echo # Setting PATH for Python ${PYVER} ${PR}
echo # The orginal version is saved in `basename ${PR}`.pysave ${PR}
echo 'PATH='${PYTHON_ROOT}/bin':${PATH}' ${PR}
echo 'export PATH' ${PR}
a file which doesn't seem to exist.
So, why didn't I notice myself checking the checkbox to do this in the
first place, and where is my original .bash_profile file?
The checkbox is on by default. Did you have a .bash_profile at all? The
scriptlet I quoted earlier indicates that the backup is created when the source
file exists.
Ronald
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?
I've got a Snow Leopard buildslave I'm trying to debug. So I thought I'd try Python 2.7 on it. Normally, I advise people to never try to install a different Python on a Mac, as it's too embedded in the OS to do safely, without a great deal of domain knowledge. But here, I figured I could always wipe the disk and start over without too much loss. So I ran the installer, and tried a few things, and it didn't solve my buildbot problems. So I decided to go back to the original System python. But now I find that the installer has put the 2.7 Python on my PATH?!? It does this apparently by hacking ~/.bash_profile. In there, there's a line saying The original version is saved in .bash_profile.pysave a file which doesn't seem to exist. So, why didn't I notice myself checking the checkbox to do this in the first place, and where is my original .bash_profile file? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?
In article 64461.1302209...@parc.com, Bill Janssen jans...@parc.com
wrote:
I've got a Snow Leopard buildslave I'm trying to debug. So I thought
I'd try Python 2.7 on it. Normally, I advise people to never try to
install a different Python on a Mac, as it's too embedded in the OS to
do safely, without a great deal of domain knowledge. But here, I
figured I could always wipe the disk and start over without too much
loss.
I don't understand why you would say that. The huge advantage of the
Python framework installation layout on OS X is precisely that it
*doesn't* get embedded into the OS and *does* allow multiple versions of
Python to co-exist on a system far more easily and safely than with the
traditional Python Unix layout. With a very few exceptions, all of the
files installed are under one root
(Library/Frameworks/Python.framework/Versions/m.n/) with some auxiliary
files under another (/Applications/Python m.n) and optionally some
symlinks in /usr/local/bin, with *zero* overlap with any Apple-supplied
files in OS X including the Apple-supplies Pythons. If for some reason
you do want to uninstall a framework build, it's a matter of two 'rm'
commands and optionally removing some obvious symlinks in /usr/local/bin
(which are not needed in the first place). An official uninstall
command would be nice to have and has been requested in the past (see
http://bugs.python.org/issue7107).
If you are aware of problems where multiple framework installs cannot be
installed safely, please open issues for them.
So I ran the installer, and tried a few things, and it didn't solve my
buildbot problems. So I decided to go back to the original System
python. But now I find that the installer has put the 2.7 Python on my
PATH?!? It does this apparently by hacking ~/.bash_profile. In there,
there's a line saying
The original version is saved in .bash_profile.pysave
a file which doesn't seem to exist.
So, why didn't I notice myself checking the checkbox to do this in the
first place, and where is my original .bash_profile file?
The Python 2.7.1 installer welcome file, the text that is shown in the
first installer screen, says this:
This package will by default update your shell profile to ensure that
this version of Python is on the search path of your shell. Please
deselect the Shell profile updater package on the package
customization screen if you want to avoid this modification.
Double-click Update Shell Profile at any time to make 2.7.1 the default
Python.
(Earlier installers had slightly different wordings.)
The command that does this is in /Applications/Python m.n/Update Shell
Profile.command. Normally, it should have saved your .bash_profile as
~/.bash_profile.pysave, but, even if it didn't, the only modification it
makes to your original .bash_profile is to append these (or similar)
lines to the end of the file:
# Setting PATH for Python 2.7
# The orginal version is saved in .bash_profile.pysave
PATH=/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}
export PATH
Hope that helps!
--
Ned Deily,
n...@acm.org
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?
In article 64461.1302209...@parc.com, Bill Janssen jans...@parc.com wrote: I've got a Snow Leopard buildslave I'm trying to debug. So I thought I'd try Python 2.7 on it. Normally, I advise people to never try to install a different Python on a Mac, as it's too embedded in the OS to do safely, without a great deal of domain knowledge. But here, I figured I could always wipe the disk and start over without too much loss. So I ran the installer, and tried a few things, and it didn't solve my buildbot problems. So I decided to go back to the original System python. But now I find that the installer has put the 2.7 Python on my PATH?!? It does this apparently by hacking ~/.bash_profile. In there, there's a line saying The original version is saved in .bash_profile.pysave a file which doesn't seem to exist. So, why didn't I notice myself checking the checkbox to do this in the first place, and where is my original .bash_profile file? 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. In any case you can revert by just deleting the extra lines. Other gripes about the installer: - It names the version explicitly instead of using the Current symlink (/Libraries/Packages/Python.Package/Versions/Current). - 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). - 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. That said, they're minor annoyances and I've not come forward to fix any of them. And the resulting python works nicely. -- Russell ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?
In article rowen-81d53b.15565607042...@news.gmane.org, Russell E. Owen ro...@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, n...@acm.org ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?
Ned Deily n...@acm.org wrote:
In article 64461.1302209...@parc.com, Bill Janssen jans...@parc.com
wrote:
I've got a Snow Leopard buildslave I'm trying to debug. So I thought
I'd try Python 2.7 on it. Normally, I advise people to never try to
install a different Python on a Mac, as it's too embedded in the OS to
do safely, without a great deal of domain knowledge. But here, I
figured I could always wipe the disk and start over without too much
loss.
I don't understand why you would say that.
I think it's gotten immensely better over the years, thanks to the
efforts of folks like you and Ronald. But I still think it tends to
have too many side-effects which surprise and confuse people.
The huge advantage of the
Python framework installation layout on OS X is precisely that it
*doesn't* get embedded into the OS and *does* allow multiple versions of
Python to co-exist on a system far more easily and safely than with the
traditional Python Unix layout. With a very few exceptions, all of the
files installed are under one root
(Library/Frameworks/Python.framework/Versions/m.n/) with some auxiliary
files under another (/Applications/Python m.n) and optionally some
symlinks in /usr/local/bin, with *zero* overlap with any Apple-supplied
files in OS X including the Apple-supplies Pythons. If for some reason
you do want to uninstall a framework build, it's a matter of two 'rm'
commands and optionally removing some obvious symlinks in /usr/local/bin
(which are not needed in the first place). An official uninstall
command would be nice to have and has been requested in the past (see
http://bugs.python.org/issue7107).
Yes, that would be nice.
So, why didn't I notice myself checking the checkbox to do this in the
first place, and where is my original .bash_profile file?
The Python 2.7.1 installer welcome file, the text that is shown in the
first installer screen, says this:
This package will by default update your shell profile to ensure that
this version of Python is on the search path of your shell. Please
deselect the Shell profile updater package on the package
customization screen if you want to avoid this modification.
Double-click Update Shell Profile at any time to make 2.7.1 the default
Python.
So it's a default operation.
(Earlier installers had slightly different wordings.)
The command that does this is in /Applications/Python m.n/Update Shell
Profile.command. Normally, it should have saved your .bash_profile as
~/.bash_profile.pysave, but, even if it didn't, the only modification it
makes to your original .bash_profile is to append these (or similar)
lines to the end of the file:
# Setting PATH for Python 2.7
# The orginal version is saved in .bash_profile.pysave
PATH=/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}
export PATH
Hope that helps!
Yes, thanks, very complete explanation. Like I said, I never run this
installer, so lack of familiarity on my part is most of the problem.
Though, I wouldn't have defaulted that path hacking to On. But I
understand the problem with the range of user knowledge you guys are
trying to cope with.
Bill
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?
On 4/7/11 3:37 PM, Ned Deily wrote:
The Python 2.7.1 installer welcome file, the text that is shown in the
first installer screen, says this:
This package will by default update your shell profile to ensure that
this version of Python is on the search path of your shell. Please
deselect the Shell profile updater package on the package
customization screen if you want to avoid this modification.
Double-click Update Shell Profile at any time to make 2.7.1 the default
Python.
(Earlier installers had slightly different wordings.)
The command that does this is in /Applications/Python m.n/Update Shell
Profile.command. Normally, it should have saved your .bash_profile as
~/.bash_profile.pysave, but, even if it didn't, the only modification it
makes to your original .bash_profile is to append these (or similar)
lines to the end of the file:
# Setting PATH for Python 2.7
# The original version is saved in .bash_profile.pysave
PATH=/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}
export PATH
And a note: before the installer did that, we had a LOT of newbies
installing python and then having no idea how to get it to run.
I'm a bit confused, Bill. You're just that kind of guy that shouldn't
have any problem hacking your .bash_profile! i.e. you are not the target
audience for the installer.
Also: I'm pretty sure it's Apple's fault that a de-installer is not a
easy and obvious part of a .mpg bundle. I don't think I've ever seen one
with a uninstaller, as a matter of fact.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?
Christopher Barker chris.bar...@noaa.gov wrote: I'm a bit confused, Bill. You're just that kind of guy that shouldn't have any problem hacking your .bash_profile! i.e. you are not the target audience for the installer. Right, I usually just build from source with a non-Framework build if I need a different Python on OS X. I just thought I'd try the easy way this one time. Also: I'm pretty sure it's Apple's fault that a de-installer is not a easy and obvious part of a .mpg bundle. I don't think I've ever seen one with a uninstaller, as a matter of fact. The package management on Macs leaves something to be desired, to be sure. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
