CODEWITHSUNDEEP
pythonwindows
Nick Hodges
Nick Hodges

Reputation: 17118

Multiple Versions of Python on my Windows machine: Which is the "right" one?

In continuing to research a solution for this question on ServerFault:

https://serverfault.com/questions/221203/mercurial-hook-fails-on-windows

I discovered an interesting and somewhat disturbing thing: I have seem three different versions of Python on my machine (four if you count the "official" version which doesn't appear to have a DLL with it....). Here's shot from my file search tool:

alt text

More Info:

I suspect that this is the source of the my problem from the question above, but I thought I'd ask here, as this is particular issue is a Python deal.

I tried to replace both DLLs with each other, but when I use the one that comes with Mercurial, then TortoiseHg stops working.

It seems to me that "there should only be one" Python on my machine. How do I achieve that?

Upvotes: 0

Views: 1221

Answers (5)

AndiDog
AndiDog

Reputation: 70158

Side note: The Python installation in "C:\Python26" installs its DLL to the Windows directory, in your case "C:\Windows\SysWOW64".

Answering your serverfault question: As you installed Mercurial as standalone version, you'll have to place any packages that are accessed by hooks into Mercurial's library folder (if it has one, could also be "library.zip").

I would recommend you to uninstall the Mercurial standalone version and instead install Mercurial with pip. This makes updates easier and you can use your normal "site-packages" directory for both normal Python libraries and hg hooks.

Upvotes: 1

Gnu Engineer
Gnu Engineer

Reputation: 1545

For the problem that you mentioned earlier, the mercurial package got installed within python under mercurial home but you are executing scripts under C:\python26. So you need to install and execute your script under mercurial python

As seth mentioned earlier it is perfectly ok to multiple python homes in the same machine but you just to pay attention when installing python libraries to make sure that you are under the right home which means you set the path right before calling python.

Upvotes: 2

Greg Buehler
Greg Buehler

Reputation: 3894

The Python DLL naming structure only provides the major version and revision numbers. You are probably looking at the DLLs for versions 2.6.1, 2.6.4, 2.6.5, and 2.6.6.

All of this doesn't really matter as long as each application contains its own copy of the python26.dll. Windows will not explore the PATH environment variable if there is a local copy of the file.

Upvotes: 0

richo
richo

Reputation: 8989

Each DLL is for that application. There is only one in your search path so you don't need to worry about conflicts.

Is something not working that prompted you to worry about this??

Your assumption that there should only be one is wrong, each application has bundled a specific version with a fixed API, you can't just drop another in and hope it'll work.

Upvotes: 0

Seth
Seth

Reputation: 46423

I would assume that tortoise/mercurial have just embedded their own versions of python to do whatever they need to do.

I wouldn't worry about it, the DLLs won't stomp on each other -- the PATH is the last placed that windows searches to find DLLs.

See: http://msdn.microsoft.com/en-us/library/7d83bc18(v=vs.80).aspx

Upvotes: 1

Related Questions