Upgrading python

[Bengt Richter]

On Wed, 30 Jul 2003 15:52:59 -0400, "John Roth" <newsgroups at jhrothjr.com> wrote:

>
>"Bengt Richter" <bokr at oz.net> wrote in message
>news:bg93pm$72v$0 at 216.39.172.122...
>> On 30 Jul 2003 06:43:22 +0200, martin at v.loewis.de (Martin v.
>=?iso-8859-15?q?L=F6wis?=) wrote:
>>
>> >Stephen Boulet <stephen at theboulets.net> writes:
>> >
>> >> When I upgrade from 2.2.3 to 2.3 on windows, do I first uninstall
>2.2.3?
>> >
>> >If you want to, you can have both 2.2 and 2.3 installed, side-by-side.
>> >If you want to replace 2.2, you should uninstall it first.
>> >
>> How do I know what will happen to file extension associations and the

 [19:00] C:\pywk\clp>assoc |findstr/i py
 .py=Pythonfile
 .py = Pythonfile
 .pyc=
 .pyo=

 [19:00] C:\pywk\clp>ftype |findstr/i py
 Pythonfile=d:\python22\python.exe "%1" %*
 Pythonfile = d:\python22\python.exe "%*"

Hm, I wonder if I did those with the extra spaces ;-/
Anyway, presumably at least one set of those will be replaced with python23 versions.

Does python itself depend anywhere on these associations? I hope not.

Also, shouldn't this be somewhere down the profile tree, so different users can 
have .html bring up their different browsers, etc.? I.e., this is really just configuring
the operation of a users's shell, it's not like NTFS vs FAT32 on a disk partition.
But that's not Python's fault.

>system path search
>> that takes unadorned python and finds some/path/to/python23.exe?
>>
>> And how does the old python22 find what it needs? Do I need to go through
>a .cmd file that
>> sets up its environment before running? How do I know everything it needs?
>>
Does the installation automatically modify the PATH (and PATHEXT??) environment
settings? For everyone, or the installing user?

>> IOW, how do you set up a clean way to run both 2.2.3 and 2.3 "side by
>side" but separately,
>> with default "python" going to 2.3?  I am being lazy in not reading the
>install docs yet,
>> but does it cover the question fully? If so, the answer to this post can
>just be "yes" ;-)
>

>As with most things having to do with installation, the answer is a bit
>complicated. On Windows, Python keeps its information in separate
>keys by major release, so there's a different key for Python 2.2 and Python
>2.3. That's compiled into the executable, so anything that's in the registry
>is kept nice and separate. So you can have two or more major releases
>side by side. You can't have two minor releases, though, because they
>use the same registry key.
>
>The keys aren't secret, so any outboard programs that need a specific
>version of Python can go right to it. Where the difficulty lies is that
>other things, such as the system path for finding executables and the
>file name associations don't have the same facility. So if I wanted to
>just be able to doubleclick on a .py or .pyc file and have it find the
>correct executable, I'm out of luck unless I do some arcane system
>programming. (That is, associate them with a program that figures
>out from the directories or the "magic number" which version of
>python is wanted, and then invokes it.)
>
I understand. But when you *do* install, does the installation unconditionally
set associations and path to the new installation?

>If all you want is for the default to be 2.3, then just make certain
>that the system path goes to the proper directory. All your
>file name associations will tag along as long as the command
>keys didn't include full paths.
Do I have to "make certain ..." by doing it manually, or just verifying if
I'm worried?

>
>And I find that .cmd files are my friends. I use them to set the
>Pythonpath so I don't have to figure out a path that's going to
>work for everything, now and forever. And they work very
>well for drag and drop targets for those little utilities that operate
>on one file...
>
Yes, I use them a lot too, especially since i/o redirection doesn't work
properly on NT4 without explicit invocation of python to run a python program.

Well, under HKEY_LOCAL_MACHINE for python I grep out

Key Name:          SOFTWARE\Python
Key Name:          SOFTWARE\Python\PythonCore
Key Name:          SOFTWARE\Python\PythonCore\2.2
Key Name:          SOFTWARE\Python\PythonCore\2.2\Help
Key Name:          SOFTWARE\Python\PythonCore\2.2\Help\Main Python Documentation
  Data:            D:\Python22\Doc\index.html
Key Name:          SOFTWARE\Python\PythonCore\2.2\InstallPath
  Data:            D:\Python22
Key Name:          SOFTWARE\Python\PythonCore\2.2\InstallPath\InstallGroup
  Data:            Python 2.2
Key Name:          SOFTWARE\Python\PythonCore\2.2\Modules
  Data:
Key Name:          SOFTWARE\Python\PythonCore\2.2\PythonPath
  Data:            D:\Python22\Lib;D:\Python22\DLLs;D:\Python22\Lib\lib-tk

Which I take it influences the following

 [17:52] C:\pywk\clp>python
 Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import os
 >>> print os.environ['PYTHONPATH']
 c:\pywk

 >>> import sys
 >>> for p in sys.path: print p
 ...

 c:\pywk
 C:\pywk\clp
 D:\python22\DLLs
 D:\python22\lib
 D:\python22\lib\lib-tk
 D:\python22
 D:\python22\lib\site-packages
 D:\python22\lib\site-packages\PIL
 

apparently the first two entries are from os.environ['PYTHONPATH'] and the working directory
that python was started in. The rest look like they're from the registry.

I can see the pattern to expect for python23 etc.

Is it possible to create a version 2.3a that would fit into this and go under a

     Key Name:          SOFTWARE\Python\PythonCore\2.3a

subtree in the registry. I mean with a single version id change someplace in the build,
not manual heroics.

Also, is there a way to have debug branches on these trees, or do you have to keep a whole
separate thing even if most is duplicated, or do you just put some debug things into
a regular tree and rely on backups to restore (as I have done with a couple experiments)

Any gotchas?

Regards,
Bengt Richter