Multiple versions of Python coexisting in the same OS
in [Python]
|
Prev: Builtn super() function. How to use it with multipleinheritance? And why should I use it at all?
Next: numpy installation
From: News123 on 25 Jul 2010 16:26 On 07/25/2010 10:18 PM, Thomas Jollans wrote: > On 07/25/2010 10:04 PM, News123 wrote: >> sOn 07/25/2010 09:39 PM, Christian Heimes wrote: >>> Am 25.07.2010 21:32, schrieb Thomas Jollans: >>>> If a script uses sys.executable instead of "python", there is no >>>> problem, at all. >> >> >> sys.executable will not work with scripts converted with py2exe, >> as sys.executable will not be the executable of the python interpreter, >> but with the main executable's name. > > Well, but a script converted with py2exe can't really ever assume that > there is a Python interpreter, at all. true :-) However, why I thought about this is, that I write sometimes python code, which tries to call other python files. later on for distribution I use py2exe. Therefore I use wrapper functions, which will work in either case. The wrapper could use sys.executable in 'python mode' and had to call the exe file in 'py2exe mode'
From: MRAB on 25 Jul 2010 16:39 News123 wrote: > On 07/25/2010 09:33 PM, Edward Diener wrote: >> On 7/25/2010 10:31 AM, News123 wrote: >>> On 07/25/2010 02:46 PM, Edward Diener wrote: >>>> On 7/25/2010 6:07 AM, Gelonida wrote: > >> How does a 'pystarter' program know where the file's location is which >> is being invoked ? > the file's location would be somewhere in sys.argv > probably in sys.argv[1]. > converting it to an abs path would return a directory which the python > file belongs to. > > >> As to the first file line this is completely >> unrealistic. What are you going to do, alter the first file line of >> every script in a Python distribution and every script in every library >> installed in a Python distribution ? Sorry, but a less intrusive >> solution is much better and much less of a headache to say the least. >> > Well I would at least do it for all of my self written scripts. > > It could allow a soft transition from 2.6 to 2.7 to 3.0 without having > to upgrade all scripts at the same time. > >> My intended solution would be a simple program which understands where >> each co-existing Python distribution is installed on a system and what >> the "name" of that distribution is. Then you tell the program which >> Python distribution should be the current one by its "name", the current >> one meaning the distribution which you want to be invoked at any given >> time. The program then changes the PATH so that any references to the >> Python directory and its subdirectories point to the "name" Python >> directory tree, and changes the file associations so that the "name" >> Python executables handle the Python associations. > > >> This does have the weakness that I can not use more than one Python >> distribution while Python is executing scripts. But I can personally >> live with that since I have never encountered a situation where I must >> use more than one Python distribution at the same time. >> > > I guess it's rather difficult to find a solution which suits all. > > The above minor weakness, that you mention would be a killer for me. > > Currently I'm looking for solutions, where I can start python scripts > requireing different python versions at the same time. > > Currently I'm staring the scripts manually from two different cmd line > windows with a different path name and an explicit python call, > > 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.
From: Edward Diener on 25 Jul 2010 17:09 On 7/25/2010 3:32 PM, Thomas Jollans wrote: > On 07/25/2010 09:19 PM, Edward Diener wrote: >> On 7/25/2010 10:03 AM, Thomas Jollans wrote: >>> On 07/25/2010 02:46 PM, Edward Diener wrote: >>>> The problem with this is that you forget that a script can invoke Python >>>> internally. So whether one uses the console or file association method >>>> of invoking Python externally, any already written script can use either >>>> internally. >>> >>> Maybe it's just me, but I think that a script that does this is quite >>> simply badly written: it *will* break on systems that have multiple >>> Python versions. >> >> Whether it is badly written or not in your opinion it is legal and >> happens all the time. Are you going to refuse to use any script, no >> matter for what library or for what purpose, that internally invokes >> Python either through a 'python' command or through a file with a Python >> extension ? And how would you find out if a script did this or not ? Are >> going to search every script in every distribution and library to >> determine if it does this ? And when you find out a script does this, >> what will you do ? >> >> Be real. saying you do not like scripts that internally invoke Python >> does not solve anything if you have multiple coexisting versions of >> Python installed. > > I doubt many scripts do it. The fact of the matter is: many systems have > multiple Python versions installed in parallel, and it probably will > break somewhere, which will get noticed, and probably fixed. > > If a script uses sys.executable instead of "python", there is no > problem, at all. What a script uses to internally invoke Python I can not control. My solution seeks to be non-intrusive and lets me run a particular version of Python, among the co-existing versions installed, at any given time. I believe that is the best I can do. I neither can control, nor do I want to control, all of the Python scripts installed on my system, nor can I worry how they may internally invoke Python. But I do want to be able to say, at any given time, that when I run Python a particular version, amidst the co-existing ones on my system, needs to be executed and therafter all internally executed modules use that version. Trying to make rules for scripts, such as telling scripts they must use sys.executable, is pursuing an imaginary solution that can not work unless one is theoretically willing to manually inspect and change all Python scripts in some way. To me any intrusive changes to actual scripts is no solution at all.
From: Edward Diener on 25 Jul 2010 17:10 On 7/25/2010 3:39 PM, Christian Heimes wrote: > Am 25.07.2010 21:32, schrieb Thomas Jollans: >> If a script uses sys.executable instead of "python", there is no >> problem, at all. > > It's true that sys.executable is the best way if you have to start a new > Python interpreter. However sys.executable may not be set for NT > services. So there may be a problem after all. > Once you start instrusively changing scripts to find a solution to multiple versions of Python co-existing in one system, you are heading down a path of endless problems.
From: Edward Diener on 25 Jul 2010 17:21
On 7/25/2010 4:26 PM, News123 wrote: > On 07/25/2010 10:18 PM, Thomas Jollans wrote: >> On 07/25/2010 10:04 PM, News123 wrote: >>> sOn 07/25/2010 09:39 PM, Christian Heimes wrote: >>>> Am 25.07.2010 21:32, schrieb Thomas Jollans: >>>>> If a script uses sys.executable instead of "python", there is no >>>>> problem, at all. >>> >>> >>> sys.executable will not work with scripts converted with py2exe, >>> as sys.executable will not be the executable of the python interpreter, >>> but with the main executable's name. >> >> Well, but a script converted with py2exe can't really ever assume that >> there is a Python interpreter, at all. > > true :-) > > > However, why I thought about this is, that > I write sometimes python code, which tries to call other python files. > > later on for distribution I use py2exe. > > Therefore I use wrapper functions, which will work in either case. > > The wrapper could use sys.executable in 'python mode' > and had to call the exe file in 'py2exe mode' > You can control what you do but how are you going to control what any givemn script does ? Attempting to intrusively change potentially every script in a distribution in any way is a path to Python hell IMO. |