homepage

I did the "make altinstall" rather than the "make
install" as suggested on
 http://www.python.org/download/releases/2.5/
This worked great, creating a 
 /usr/local/bin/python2.5
which doesn't clash with my /usr/bin/python. However,
it also created a
 /usr/local/bin/pydoc
which did clash with my /usr/bin/pydoc. I just removed
it and all is well. Should altinstall not create pydoc?
It could create pydoc2.5 rather than pydoc, but then
the shebang line would have to be changed to python2.5.
What about smtpd.py, idle, and python-config, which
were also created by altinstall? They don't currently
conflict with anything I have for Python 2.4, but the
potential is there for the same problem.

Logged In: YES 
user_id=21627
You are right: altinstall shouldn't overwrite these
conflicting files. For idle and pydoc, I would think that
altinstall should install version-specific copies - users
actually might want to run an idle or pydoc associated with
a specific version, likewise for python-config. I'm
uncertain why smtpd.py is installed at all.
Would you be willing to work on a patch? You are right that
the shebang line should get updated during the installation,
too.

Logged In: YES 
user_id=827666
I'm not sure I know how. It looks like the downloaded files
have the following shebang lines
 Tools/scripts/pydoc => #!/usr/bin/env python
 Tools/scripts/idle => #! /usr/bin/env python
 Lib/smtpd.py => #! /usr/bin/env python
 Misc/python-config.in => #!@BINDIR@/python
whereas the installed files have
 /usr/local/bin/pydoc => #!/usr/local/bin/python
 /usr/local/bin/idle => #!/usr/local/bin/python
 /usr/local/bin/smtpd.py => #!/usr/local/bin/python
 /usr/local/bin/python-config => #!/usr/local/bin/python
so they're already getting rewritten somewhere. We want both
their names and their shebang lines to have the version
 /usr/local/bin/pydoc2.5 => #!/usr/local/bin/python2.5
 /usr/local/bin/idle2.5 => #!/usr/local/bin/python2.5
 /usr/local/bin/smtpd.py2.5 => #!/usr/local/bin/python2.5
 /usr/local/bin/python-config2.5 => #!/usr/local/bin/python2.5
It seems that python-config appears in the Makefile, so
adding something like
	sed -e "s,@BINDIR@,$(BINDIR)," <
$(srcdir)/Misc/python-config.in >python-config$(VERSION)$(EXE)
	$(INSTALL_SCRIPT) python-config
$(BINDIR)/python-config$(VERSION)$(EXE)
	rm python-config
to Makefile.pre.in in an altlibainstall section or something
might be all we need for that.
The others are named in setup.py
 # Scripts to install
 scripts = ['Tools/scripts/pydoc',
'Tools/scripts/idle',
 'Lib/smtpd.py']
but I haven't worked out where they get rewritten or
installed yet.

Logged In: YES 
user_id=827666
Sorry, I haven't had a chance to look at this again. I just
installed Python-2.5b1 and it's still the same way. Here's
what I did to fix things up after the make altinstall...
 # cd /usr/local/bin
 # for file in pydoc idle smtpd.py python-config; do
 mv $file ${file}2.5
 sed -i 's@/usr/local/bin/python@/usr/local/bin/python2.5@'
${file}2.5
 done
Now, how to fix up the Makefile.pre and setup.py so this
isn't necessary...

Logged In: YES 
user_id=1581732
Ah, it's a bit worse than that. Your /usr/loca/bin/pydoc
would not have worked anyway. It's first line:
#!/usr/local/bin/python
would give an error because only /usr/local/bin/python2.5
exists.

Logged In: YES 
user_id=827666
Yeah, that's what the sed command is for.
By the way, it looks like python-config is taken care of in
release candidate 1. That is, after doing the altinstall for
2.5c1, I did
 # for file in pydoc idle smtpd.py; do
 mv $file ${file}2.5
 sed -i
's@/usr/local/bin/python@/usr/local/bin/python2.5@' ${file}2.5
 done
to fix things up.

Logged In: YES 
user_id=1581732
A bit more background; I'm starting to appreciate the
problem. The makefile plays a part, but the real problem is
down is down in Lib/distutils/command/install_scripts.py.
Makefile/altinstall builds
Makefile/sharedinstall executes
setup.py imports
distutils.core/setup() invokes indirectly
distuitls.commands/install_scripts.py
And install_scripts.py needs to be taught about the
suffixes, or be passed a new destination filename.
Note that setup() must be backward compatible back several
versions. 
So it seems like the problems are:
1. Change the Makefile target sharedinstall to somehow pass
the right suffix into setup. Also make sharedinstall alter
the scripts to call the right version of python.
2. Change the Makefile target bininstall to add hard links
for the scripts, e.g., from pydoc2.5 to pydoc.
3. Somehow pick up the parameters in
Lib/distutils/commands/install_scripts.py and tack on the
right suffix when copying.
I'll whack at it tomorrow.

Logged In: YES 
user_id=21627
I don't think you have to pass the version to setup.py. Instead, setup.py can just 
use sys.version_info (since it is being run with the "right" interpreter).

Seems to have resurfaced on 3.0, see issue 3744.

Fixed on #1590.