Missing symlink:Current after Mac OS X 3.3.2 package installation

[gavan]

BPO	18117
Nosy	@ronaldoussoren, @ned-deily, @bitdancer

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/ronaldoussoren'
closed_at = <Date 2016-06-04.22:27:50.350>
created_at = <Date 2013-06-02.08:29:43.312>
labels = ['OS-mac', 'type-bug', 'expert-installation']
title = 'Missing symlink:Current after Mac OS X 3.3.2 package installation'
updated_at = <Date 2016-06-04.22:27:50.349>
user = 'https://bugs.python.org/gavan'

bugs.python.org fields:

activity = <Date 2016-06-04.22:27:50.349>
actor = 'ned.deily'
assignee = 'ronaldoussoren'
closed = True
closed_date = <Date 2016-06-04.22:27:50.350>
closer = 'ned.deily'
components = ['Installation', 'macOS']
creation = <Date 2013-06-02.08:29:43.312>
creator = 'gavan'
dependencies = []
files = []
hgrepos = []
issue_num = 18117
keywords = []
message_count = 8.0
messages = ['190474', '190490', '190505', '190530', '190536', '190537', '266717', '267333']
nosy_count = 4.0
nosy_names = ['ronaldoussoren', 'ned.deily', 'r.david.murray', 'gavan']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue18117'
versions = ['Python 3.4']

[gavan]

There is a missing symlink.

Context:
Installed package:
<http://www.python.org/ftp/python/3.3.2/python-3.3.2-macosx10.6.dmg\>
with no apparent problems onto a 'clean' system, i.e., no other python packages other than OS X 10.8.3 defaults.

Found the following in /Library/Frameworks/Python.framework:
pendari:Python.framework postgres$ ls -las
total 24
0 drwxr-xr-x 3 root wheel 204 14 May 06:49 .
0 drwxr-xr-x 8 root wheel 374 2 Jun 17:06 ..
8 lrwxr-xr-x 1 root wheel 24 2 Jun 17:06 Headers -> Versions/Current/Headers
8 lrwxr-xr-x 1 root wheel 23 2 Jun 17:06 Python -> Versions/Current/Python
8 lrwxr-xr-x 1 root wheel 26 2 Jun 17:06 Resources -> Versions/Current/Resources
0 drwxr-xr-x 3 root wheel 102 14 May 06:54 Versions

However:
pendari:Versions postgres$ ls -las
total 0
0 drwxr-xr-x 3 root wheel 102 14 May 06:54 .
0 drwxr-xr-x 3 root wheel 204 14 May 06:49 ..
0 drwxrwxr-x 7 root admin 306 14 May 06:54 3.3

Specifically we are missing the following from .../Versions:
8 lrwxr-xr-x 1 root wheel 3 2 Jun 17:27 Current -> 3.3

to make all the other symlinks work as intended.

This also implies the ~/.bash_profile patch would be improved if the existing:
PATH="/Library/Frameworks/Python.framework/Versions/3.3/bin:${PATH}"
was replaced by:
PATH="/Library/Frameworks/Python.framework/Versions/Current/bin:${PATH}"

Apologies if this has already been reported. It is my first report so I could easily have missed something: I searched with terms "installer mac".

Regards
Gavan Schneider

[ned-deily]

That behavior of the OS X installer is by design. Currently, the "Current" link is only set for Python 2 installations, not Python 3 ones. While that may have made sense in the early days of Python 3 (assuming there would be mixed installations of both Python 3 and Python 2 to the same framework), that is probably no longer a good idea. Considering the difference between Python 2 and 3 at the API level and that one of the reasons for installing as a framework should be to simplify linking with Python libraries, I've been thinking that it might be a good idea to have Python 3 install in its own framework, say Python3. Or some other arrangement. As it stands today, 'cc ... -framework Python ...' isn't usable for Python 3 out of the box.

[gavan]

Appreciate the comment about potential problems with mixed installations of python3 and python2. And note that along these lines there is no attempt by the installer to symlink python -> python3 (which could have nasty side effects if the full path was not specified in system applications).

However there is still a problem: the installer is creating three dead symlinks, which is not correct.

Agree putting Python3 into its own /Library/Frameworks/Python3.framework would be a better way to go.

[ronaldoussoren]

Linking with "-framework Python" is always a bad idea because you have no control over which version of Python you link with other than by changing global system state (the Current link). Also: include files aren't included using the framework conventions (e.g. we use "#include <Python.h>", not "#include <Python/Python.h>").

I'd prefer to remove the Current link from "from source" installs instead adding them to the py3k installer, that makes is clearer that you are not supposed to use "-framework Python".

I'm also not too keen on renaming the Python framework for Python 3.4.

[gavan]

A lot of this is past my level but speaking from my level I just want packages to be consistent, i.e., if there is a symlink it should point to something (preferably useful) not dangle as is the case now.

Also I want an installed version to "look the same" no matter what version it might be. Specifically the version number should only occur once in the file tree. This then allows me to specify ***at the system level*** what I want when invoking (via a Current or similar link) my postgres and other build scripts, specifically so they don't need to be hand crafted just so they build against new new and latest install.

If I ever get to the stage where I am building to a specific version that's not the global selection I can do that by taking proper steps (but that's not what I usually want to do after installing a new version).

Continuing in the vein of one only mention of the version number in the package tree: why is there a python3.3 folder inside .../Pyton.framework/Versions/3.3/lib? Won't lib/Python3.4 stuff get put in its own Version?

As for the reluctance to rename the package for 3.4. Wont it be Python3 and the rename could just as logically be done for the current release:
/Library/Frameworks/
Python.framework/... # all the Pyton 2 stuff
Python3.famework
Versions
3.3/...
3.4/...
Current -> 3.4
...

Finally there seems to be a convention with all the other installed packages for a "Current" symlink (note especially Tcl/Tk) to do something useful within their respective "Versions" folder. Is it too much to suggest that Python just follow this convention (albeit with the package name changed to pyton3 to prevent potential conflicts)?

Anyway, please excuse my drifting so far from a simple report of a broken and/or missing installer link :)

Regards
Gavan Schneider

[ronaldoussoren]

There is a python3.3 in .../Python.framework/Versions/3.3/lib because .../Python.framework/Versions/3.3 is basicly a regular unix install with some trivial changes (in particular, there is a Python shared library in the root of the tree, there is a Python.app and bin/python isn't the real interpreter but a stub).

Keeping the framework close to a regular unix install is an explicit design choice, it minimizes the difference from those unix installs and reduces the amount of needless incompatibilities (for example with scripts that run on unix-like systems and assume a particular layout of sys.prefix)

I try to avoid relying on the Current symlink because it depends on the order in which packages are installed, for example when you have two version of Python installed and update one of them the Current link may change even if you might not want to. Futhermore the Current link can only be changed by users with elevated privileges (an "admin" account or root).

Again, I don't think renaming the framework for Python 3 would be useful and even if it were done it could only be done for Python 3.4 al existing releases of Py3k would still use Python.framework because changing the framework name will break existing installations when installing an update with a changed framework name.

[bitdancer]

Ned, can this issue be closed or is there still something to discuss here?

[ned-deily]

David, I think we are not going to change the Current symlink behavior at this point so we might as well close this issue. We may decide to address the need to pick which version to link with in a different manner later.