[Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)
In article <4F3CD403.7070102 at v.loewis.de>,
"Martin v. Lowis" <martin at v.loewis.de> wrote:
> > There are two issues that I know of for OS X. One is just getting a
> > python2 symlink into the bin directory of a framework build. That's
> > easy.
> Where exactly in the Makefile is that reflected? ISTM that the current
> patch already covers that, since the framwork* targets are not concerned
> with the bin directory.
When a framework build is enabled in configure, several additional
targets from Mac/Makefile are called from the main Makefile. The
creating of the links in the framework bin directory and in $prefix/bin
(/usr/local/bin) are handled there. (See the checked in patch for 2.7
for gory details: http://hg.python.org/cpython/rev/499796937b7a)
> > The other is managing symlinks (python, python2, and python3)
> > across framework bin directories; currently there's no infrastructure
> > for that. That part will probably have to wait until PyCon.
> What is the "framework bin directory"? The links are proposed for
> /usr/local/bin resp. /usr/bin. The proposed patch already manages
> these links across releases (the most recent install wins).
The framework bin directory is a bin directory within a framework. The
default location for 2.7 is:
This is where the python executable, aux programs like idle, 2to3,
pydoc, python-config, as well as all Distutils-installed scripts go.
Mac/Makefile and the Mac installer each optionally create symlinks from
/usr/local/bin (default) to the items in the framework bin directory at
build or install time for the standard items but not for subsequent
Distutils-installed scripts. Normally, the /usr/local/bin links are not
needed with framework builds as the framework bin directory is added to
the user's $PATH during installation.
> If you are concerned about multiple feature releases: this is not an
> issue, since the links are just proposed for Python 2.7 (distributions
> may also add them for 2.6 and earlier, but we are not going to make
> a release in that direction).
It is more of an issue for multiple Python 3 versions. But the whole
mechanism of managing multiple framework versions (2 and/or 3) is messy
right now. But that's a separate topic that I plan to address later.
As for now, I believe all that is needed for PEP 394 is now checked-in.
nad at acm.org