thecocce / pyscripter

Automatically exported from code.google.com/p/pyscripter
0 stars 0 forks source link

pyscripter picks up 'wrong' python version #428

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

1. select a python source file in windows explorer
2. right-click on it
3. select 'edit with pyscripter'

What is the expected output? What do you see instead?

I expect pyscripter to use the version of python that is 'formally' installed 
as far as windows is concerned, instead pyscripter uses a python version that 
it finds 'somehwere' on the system.

What version of the product are you using? On what operating system?

pyscripter-2.3.1.0
windows xp/sp3

Please provide any additional information below.

Before I start: Thank you for the great IDE !!!

This is an issue that I have brought up before, but never got a satisfying 
answer to (possibly due to not being clear enough on my side?)

When I launch pyscripter without any argements, pyscripter simply ignores
1. the settings in the windows registry related to the 'formally' installed 
python version (pointing to python2.5 in my case)
2. the normal windows search path (which only includes c:\python25\bin in my 
case)
but instead performs a complete search of the system to find the highest 
version of python it can find, and uses that.

In fact, I do have a python2.6 installation under Cygwin (for use in 
combination with Cygwin) but there is no reference to it in the registry, nor 
on the windows system path.

I know that I can use --PYTHON25 as an argument to pyscripter.exe to force a 
specific version of python to be used (and there are in fact, several shortcuts 
provided in pyscripter's 'start menu' folder that allow launching of it using a 
specific python version)

I would however expect, that if I launch pyscripter.exe without any arguments, 
that it would use the python version as 'indicated' in the registry (and evt 
the system path).

I can easily live with the approach of adding a --pythonXX argument, however, 
recently I started using the (convenient) 'edit with pyscripter' context menu, 
and ran into the same problems that I had before.

When I use the context menu, pyscripter is launched with one argument: the full 
pathname of the file to be edited, and reverts to its build-in logic of finding 
the highest python version, which is not the one that I want!

I do not want that version, because I only have Rpyc installed for the version 
of python that is 'formally' installed under windows.

So, my question remains: why oh why does pyscripter (imho stubbornly) insist on 
ignoring the windows settings, and start using the highest version of python on 
the system (which does not have the Rpyc module installed)

To launch pyscripter using a specific version of python, 8 dedicated 
'pyscripter for python x.x' shortcuts are provided in pyscripter's 'start menu' 
folder, but extending the explorer context menu with 8 specific 'edit with 
pyscripter using python x.x' entries seems a bit awkward to me.

Why not make pyscripter simply 'respect' the user's environment and only 
deviate from it on request using the --pyhtonXX argument?

Ton van Vliet.

Original issue reported on code.google.com by epposan@gmail.com on 17 Oct 2010 at 4:52

GoogleCodeExporter commented 9 years ago
As designed.  See also Issue #395.  You can setup PyScripter so the "Edit with 
PyScripter works with a specific version of Python.

From the help file:  See at the bottom.

Command-line Options 

--------------------------------------------------------------------------------

When invoked without any arguments PyScripter will load the latest version of 
Python and restore the files which were open when the last editing session 
ended.  If no files were open an empty Python module is created.   This 
behavior can be changed with command-line arguments:

PyScripter [--pythonversion] filename1 filename2 ...

where
            pythonversion can be PYTHON23, PYTHON24 etc.

if pythonversion is provided on the command-line PyScripter tries to use that 
version if it is available and PyScripter has been compiled for a version lower 
to or equal to that version.

If one or more filenames are provided on the command-line they are opened when 
PyScripter starts.

Other command line flags:

--PROJECT filename
Open a specific PyScripter project file 

--PYTHONDLLPATH
In order to allow PyScripter to work with unregistered version of Python such 
as Portable Python,  another command line argument is provided PYTHONDLLPATH. 
When such an argument is provided the registry search is bypassed and the 
Python DLL found in that path is used instead.  

e.g.  PyScripter --PYTHON25 --PYTHONPATHDLL "E:\PortablePython" 

See Using PyScripter with Unregistered Python for more information

--NEWINSTANCE or -N
If set a new instance of Pyscripter is started.  This to prevent the default 
behavior which is to activate an existing instance of PyScripter is one is 
running.

--DPIAWARE or -D
When using large font sizes (high DPI) in Windows Vista, and not using XP style 
scaling, text may appear blurry and tiring to the eyes.  You can set this 
command line flag to avoid such effect.

--DEBUG or -B
Instructs PyScripter to use the debug version of PyScripter . (e.g. 
Python25_d.dll). You should use debut versions of all extension modules that 
you may want to load.

NOTE
Since version 1.85 PyScripter options are marked with two dashes "--".

Further information on --PYTHONDLLPATH

There are two types of Python installation
a)  For all users
Python creates registry entries at HKEY_LOCAL_MACHINE\SOFTWARE\Python
\PythonCore\2.x  with installation info and puts the dll in c:\Windows
\System32.
b)  For a single user
Python creates registry entries at HKEY_CURRENT_USER\SOFTWARE\Python
\PythonCore\2.x  with installation info and does not put the dll in c:
\Windows\System32.

PyScripter without any command line flags looks at the registry to find the 
latest version of Python and then for an all user installation tries to load 
the relevant Python dll from the system path.  For a single user installation 
tries to load the DLL from the Install path that is in the registry.

When PyScripter is used with a --PYTHONxx flag then it does the above but 
searching only for the specific version. The Registry lookup does not take 
place when Python is used with the --PYTHONDLLPATH.  Instead PyScripter tries 
to load the Python dll from the specified path.

The --PYTHONDLLPATH flag should be used with the --PYTHONxx flag.  See 
http://pyscripter.googlepages.com/portablepython for an example of using 
PyScripter with portable Python.

The %PYTHONHOME% environment variable is not used by PyScripter directly but by
Python to find the installed libraries.  See the Python documentation for its 
use. 

Original comment by pyscripter on 17 Oct 2010 at 5:14

GoogleCodeExporter commented 9 years ago
Sorry the link above should be 
http://code.google.com/p/pyscripter/wiki/FAQ#How_do_I_use_PyScripter_with_Portab
le_%28Movable%29_Python?

Original comment by pyscripter on 17 Oct 2010 at 5:19

GoogleCodeExporter commented 9 years ago
Thanks for the quick response.

pyscripter does NOT seem to follow these rules however!

Close to the end the following is stated:

<quote>
PyScripter without any command line flags looks at the registry to find the 
latest version of Python and then for an all user installation tries to load 
the relevant Python dll from the system path.  For a single user installation 
tries to load the DLL from the Install path that is in the registry.
<unquote>

This is in fact what I expect (and hoped for), but unfortunately is not what is 
happening.

All PythonCore related settings in my registry point to python25 and python25 
is installed accordingly (including a reference to c:\python25 in windows path 
environment variable), nevertheless pyscripter ignores these settings and uses 
python26 !

Original comment by epposan@gmail.com on 17 Oct 2010 at 7:26

GoogleCodeExporter commented 9 years ago
Without any command line option PyScripter tries to find the latest version.  
If it finds python26.dll in the system path it uses it.  If you want to use 
python25 why don't you just start PyScripter with the --python25 command line 
option?

If you want to python25 to be loaded when used with the "Edit with PyScripter" 
shell extension then:
-  Start PyScripter with admin rights and --python25
-  Go to the IDE options and uncheck the Shell extension option.
-  Press OK
-  Go to the IDE options again and check the Shell extension option. 
-  Press OK
-  Exit PyScripter

From now on when you use the "Edit with PyScripter" shell extension it will be 
loaded with python25.

Original comment by pyscripter on 17 Oct 2010 at 8:35

GoogleCodeExporter commented 9 years ago
Thanks for this solution. The shell extension works fine now!

However, please 'bear with me' just a little longer, to find out why (possibly 
only in my case) the determination of the 'latest version' does what it does?

2 questions:

1. When pyscripter tries to find the latest version, 'does it' or 'does it not' 
look at the registry settings ?

2. Possibly I misunderstand the term 'system path': is it the system's PATH 
environment variable, or is it the sys.path variable of the 'sys' module

Original comment by epposan@gmail.com on 18 Oct 2010 at 6:21

GoogleCodeExporter commented 9 years ago
The main reason for continuing on this 'issue' is, that under windows (and I am 
sure you are 100% aware of this) the association between files with python 
related extensions and the 'program' to be used for it, is done by settings in 
the windows registry. Windows users (unfortunately) cannot make use of any 
'shebang' line at the start of a python source code file.

Now, if today I am working with python version 2.5, it would be very convenient 
if both pyscripter and the 'edit with pyscripter' shell extension would simply 
pick up this setting and use python 2.5

and similarly, if tomorrow I am working with python version 2.6, it would be 
very convenient if both pyscripter and the 'edit with pyscripter' would simply 
pick up this setting and use python 2.6, without me having to select another 
shortcut link to launch pyscripter with the appropriate --pythnXX argument, or 
going to change pyscripter's 'shell extension' option.

Original comment by epposan@gmail.com on 18 Oct 2010 at 6:51

GoogleCodeExporter commented 9 years ago
2 questions:

1. When pyscripter tries to find the latest version, 'does it' or 'does it not' 
look at the registry settings ?

What PyScripter does is:
- Tries to load the latest version say python32.
- To find where to load it from it looks at the registry key 
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\3.2 (All users).  If it finds the 
key it assumes the dll is in the system path and tries to load it.
- If the previous key does not exist it looks at  
HKEY_CURRENT_USER\SOFTWARE\Python
\PythonCore\3.2 (Single user) and it tries to load the DLL from the path 
specified in the registry.
- If there is no info in the registry it still tries to load it from the system 
path to cater for unregistered Python versions.  This is what it was happening 
in your case.

2. Possibly I misunderstand the term 'system path': is it the system's PATH 
environment variable, or is it the sys.path variable of the 'sys' module
The former.

If you have multiple Python versions installed only one of them is associated 
with .py files (is "registered").  PyScripter does not look at that at all.  I 
suppose there could be another startup option, --USE_REGISTERED_VERSION or 
something that would use the registered version instead of the latest.  If you 
want something like that please submit a new issue.

Original comment by pyscripter on 18 Oct 2010 at 9:18

GoogleCodeExporter commented 9 years ago
Thanks for your patience!

Your answer to question 1 is still ambiguous (to me)

What makes pyscripter (in your example) decide that python32 is the latest 
version?

Does it take this information from the python.org site ?
Does it perform a search for pythonXX.dll's on all drives ?
Does it use the value as set in the HKLM or HKCU PythonCore ?
Does it do something else ?

Your answer to question 2 is clear to me, but it is relatively easy to change 
these settings (globally). I came to the question from reading your comment #4, 
which states: "if it finds python26.dll in the system path it uses it"

Original comment by epposan@gmail.com on 18 Oct 2010 at 12:42

GoogleCodeExporter commented 9 years ago
By latest version I mean the highest numbered version known to PyScripter.  The 
current version of PyScripter knows about versions 3.2, 3.1, 3.0, 2.7 down to 
2.3 and tries to load them in that order.

I already said that by system path I mean the system's PATH environment 
variable.  With these clarifications please read my earlier comment since it 
contains the answers to all your questions and I cannot state it any more 
clearly.

Original comment by pyscripter on 18 Oct 2010 at 4:22

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Not exactly.

Let me just repeat.

Currently PyScripter knows of version 3.2, 3.1, 3.0, 2.7...2.3.  Below, system 
path refers to the Windows path (environment variable) and x.x refers to the 
version number.

Repeat for versions 3.2 down to 2.3:

    * Look at the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\x.x (All users).  If key is found assume the dll is in the system path and try to load it.
    * If the previous key does not exist it look at  HKEY_CURRENT_USER\SOFTWARE\Python\PythonCore\x.x (Single user) and try to load the Python DLL from the path specified in the registry.
    * If there is no info in the registry try to load the DLL from the system path to cater for unregistered Python versions.
    * If Python DLL was loaded successfully then break

Original comment by pyscripter on 18 Oct 2010 at 7:10

GoogleCodeExporter commented 9 years ago
Sorry! I had deleted comment #10 because I knew there was something wrong with 
my summary, and wanted to take a little bit more time to get it right, but 
obviously you beat me to it :)

I think it is clear (even to me :) now.

Summarizing again:
If a version of python is found on the system path that is higher than the 
formally installed version, pyscripter will use that higher version and ignore 
the formally installed version, even if the folder containing the higher 
version was put on the system path as a side product of installing 'some other 
program'

Original comment by epposan@gmail.com on 18 Oct 2010 at 8:25