Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Multiple versions of Python coexisting in the same OS

Reply
Thread Tools

Multiple versions of Python coexisting in the same OS

 
 
Dennis Lee Bieber
Guest
Posts: n/a
 
      07-26-2010
On Sun, 25 Jul 2010 20:40:16 -0400, Edward Diener
<(E-Mail Removed)> declaimed the following in
gmane.comp.python.general:

> So if a standard library module ( or distributed library ) executes a
> call internally to 'python xxx yyy' or executes a call internally to
> 'someScript.py yyy', you're fine with multiple co-existing versions of
> Python on your system ?
>

I highly doubt any "standard" library will rely upon the ability to
spawn independent processes that are subject to the vagaries of the
user's system configuration.

Likewise, any 3rd party library that performs process spawning had
better document, right up front (before I even download it) that it
performs such behavior.

To me, a "library", by definition is meant to work within the
process space that invokes it. That process space may not be compatible
with the installed Python -- but that should mean the library itself
will not function/install; not that it will appear to function and then
fail due to some external process not being compatible.
--
Wulfraed Dennis Lee Bieber AF6VN
http://www.velocityreviews.com/forums/(E-Mail Removed) HTTP://wlfraed.home.netcom.com/

 
Reply With Quote
 
 
 
 
Edward Diener
Guest
Posts: n/a
 
      07-26-2010
On 7/25/2010 10:42 PM, David Robinow wrote:
> On Sun, Jul 25, 2010 at 8:40 PM, Edward Diener
> <(E-Mail Removed)> wrote:
>> On 7/25/2010 5:57 PM, Thomas Jollans wrote:
>> So if a standard library module ( or distributed library ) executes a call
>> internally to 'python xxx yyy' or executes a call internally to
>> 'someScript.py yyy', you're fine with multiple co-existing versions of
>> Python on your system ?
>>
>> Because under Windows the first call will look for the python.exe first
>> found in the PATH while the second call will find the python.exe associated
>> with the .py extension. And it does not matter in either case what version
>> of the multiple installed versions of Python which are on my system is
>> currently executing that script.
>>
>> And please don't say that there is some sort of guarantee that no library or
>> installation would invoke Python in such a way as opposed to the normal
>> 'import AScript.py' method of using functionality in Python scripts.

> Edward, I'm having a really hard time understanding your problem.
> Could you give an example of some real code that is causing you
> difficulty?


I start a Python script for version X by going to X's root directory and
invoking 'python someScript.py' from the command line. Does that not
sound reasonable ?

In SomeScript.py there is an internal call to 'python someOtherScript.y
someParameters'. But the call invokes another version of Python because
it is that version which is in the PATH. Or in SomeScript.py there is an
internal call to 'someOtherScript.py someParameters'. But the call
invokes another version of Python because the .py extension is
associated with a different version.

My solution is that I will write some code which sets a particular
version of Python as the current version for a particular time, meaning
that version will be in the PATH and associated with Python extensions.
The way I do not have to worry when I externally invoke Python from the
command line that internal calls are going to some other version.
 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      07-26-2010
On Mon, 26 Jul 2010 00:36:47 -0400, Edward Diener wrote:

> On 7/25/2010 10:42 PM, David Robinow wrote:

[...]
>> Edward, I'm having a really hard time understanding your problem. Could
>> you give an example of some real code that is causing you difficulty?

>
> I start a Python script for version X by going to X's root directory and
> invoking 'python someScript.py' from the command line. Does that not
> sound reasonable ?


No it doesn't, it's a very unreasonable thing to do.

If you have multiple versions of Python, you should name them
appropriately so you can launch the appropriate version from any
directory:

python26 someScript.py # calls python31 secondScript.py internally
python31 anotherScript.py # calls python25 thirdScript.py internally

etc.

Or give the full path to the executable:

C:\Programs\python26\python.exe someScript.py
# calls C:\Programs\python31\python.exe secondScript.py internally


If a script doesn't do this, then the script should be treated as buggy.



> In SomeScript.py there is an internal call to 'python someOtherScript.y
> someParameters'.


That's a pretty dodgy thing to do in the first place, unless you can
guarantee that there's only one executable called python. Otherwise, how
do you know which one will be called? You can't easily predict which one
will be called, so don't do it unless you want your scripts to call
arbitrary executables.



> But the call invokes another version of Python because
> it is that version which is in the PATH. Or in SomeScript.py there is an
> internal call to 'someOtherScript.py someParameters'. But the call
> invokes another version of Python because the .py extension is
> associated with a different version.


Exactly. The root of your problem is that there are multiple executables
called "python" and you don't know which one you will get. So don't do
that.


> My solution is that I will write some code which sets a particular
> version of Python as the current version for a particular time, meaning
> that version will be in the PATH and associated with Python extensions.


/facepalm


> The way I do not have to worry when I externally invoke Python from the
> command line that internal calls are going to some other version.



Good luck with that.



--
Steven
 
Reply With Quote
 
Gelonida
Guest
Posts: n/a
 
      07-26-2010

>>
>> Thus my idea of having a pystarter with a config file
>> mentioning which directories (tools) should use which python executable

>
> Well, good luck ! I don;t know how this is resolved for you when some
> scripts executes 'python xxx yyy' or 'someScript.py yyy'.


both could be resolved with a python starter if one wanted.

call the python starter python.exe and put it first in the path.
set the python file associations to the python starter.


By the way:

Something similiar (not identical) has been used for linux hosts in big
companies in order to easily switch between different projects. (which
potentilly had different versions of development tools)

instead of having multiple .cshrc / .bashrc files

the first entry of path has been set to
/_WRAPPER_/bin (or something similiar)
in this directory one found a wrapper script for each tool to be
wrapped. ( one script, many symlinks for each tool)

the wrapper script took a global setup, the project name and a private
setup to finally call the the desired script.

What is missing is to choose the executable depending on the script to
be called.

If one has a wrapper this could be added.

Just a question of style, whether the decision which script to be called
should come from the
- user
- a config file ( No script to be intrusively changed, what Edward seems
to prefer )
- some coding in the script or the tool's directory ( which MRAB seems
to prefer )






 
Reply With Quote
 
Gelonida
Guest
Posts: n/a
 
      07-26-2010
On 07/25/2010 10:39 PM, MRAB wrote:
> News123 wrote:


>> Thus my idea of having a pystarter with a config file
>> mentioning which directories (tools) should use which python executable
>>

> I think that's the wrong way round. A pystarter should ask the _tool_
> which version of Python it needs.



Hm, it's dfifficult to think about a solution satisfying everyone.

Edward seems to insist on a non intrusive solution, where no script is
changed (thus my idea of a config file)


I personally would probably add information to all of my self written
scripts
and create a config file for all other tools (or add a marker file n the
path of these tools)


 
Reply With Quote
 
Gelonida
Guest
Posts: n/a
 
      07-26-2010
On 07/26/2010 06:36 AM, Edward Diener wrote:
>
> I start a Python script for version X by going to X's root directory and
> invoking 'python someScript.py' from the command line. Does that not
> sound reasonable ?


Do you have an example of two (not self written) applications requiring
to change the python file association in order to be working?

I never had problems with this, so would be curious about the tools to
avoid.



Apart from that my suggestion for you would be:


Don't write a tool.
Just create one .bat file for each sript to be started.

The bat file should set the python search path.
This should cover 90% of existing python scripts.
(If you want, you could write a tool to create the bat files)


Now the second problem.

if a python script starts another python file without calling python.exe
but via the file associations, then above solution would not be sufficient/
you had to additionally change the file associations,
(which can easily be done from a bat file as well if you insist. The
commands you need are 'assoc' and 'ftype')

But does this really happen to you?



Please note:
Trying to develop a solution, which believes that you will never have
two concurrent applications requiring two differnt python versions
sounds a little dangerous.

 
Reply With Quote
 
Thomas Jollans
Guest
Posts: n/a
 
      07-26-2010
On 07/26/2010 06:36 AM, Edward Diener wrote:
> On 7/25/2010 10:42 PM, David Robinow wrote:
>> On Sun, Jul 25, 2010 at 8:40 PM, Edward Diener
>> <(E-Mail Removed)> wrote:
>>> On 7/25/2010 5:57 PM, Thomas Jollans wrote:
>>> So if a standard library module ( or distributed library ) executes a
>>> call
>>> internally to 'python xxx yyy' or executes a call internally to
>>> 'someScript.py yyy', you're fine with multiple co-existing versions of
>>> Python on your system ?
>>>
>>> Because under Windows the first call will look for the python.exe first
>>> found in the PATH while the second call will find the python.exe
>>> associated
>>> with the .py extension. And it does not matter in either case what
>>> version
>>> of the multiple installed versions of Python which are on my system is
>>> currently executing that script.
>>>
>>> And please don't say that there is some sort of guarantee that no
>>> library or
>>> installation would invoke Python in such a way as opposed to the normal
>>> 'import AScript.py' method of using functionality in Python scripts.

>> Edward, I'm having a really hard time understanding your problem.
>> Could you give an example of some real code that is causing you
>> difficulty?

>
> I start a Python script for version X by going to X's root directory and
> invoking 'python someScript.py' from the command line. Does that not
> sound reasonable ?


yeah, well, sort of. But for a system installation, not really. When
hacking on the interpreter, this makes sense. Otherwise - not so much.

>
> In SomeScript.py there is an internal call to 'python someOtherScript.y
> someParameters'.


Is that a fact?

Where on earth did you get this "SomeScript.py"?

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Loading multiple versions of the same package at the same time della Python 6 11-28-2008 11:08 AM
Tomcat/Apache coexisting Ike Java 4 10-04-2006 12:48 PM
"Cannot find assembly" problem with .NET 1.1 and 2.0 coexisting Nils Magnus Englund ASP .Net 3 09-07-2006 03:05 PM
Running multiple versions of Python on the same host.. Cowmix Python 3 07-10-2006 06:04 PM
Multiple versions of Python / PythonWin on the same machine? dananrg@yahoo.com Python 2 02-24-2006 11:17 PM



Advertisments