classification
Title: /usr/bin surprisingly in sys.path under IDLE
Type: behavior Stage: resolved
Components: IDLE Versions: Python 3.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: terry.reedy Nosy List: cheryl.sabella, doko, epaine, phr, terry.reedy
Priority: normal Keywords:

Created on 2020-05-22 20:35 by phr, last changed 2020-07-14 21:06 by terry.reedy. This issue is now closed.

Messages (9)
msg369643 - (view) Author: paul rubin (phr) Date: 2020-05-22 20:35
This is in the standard python 3.7.3 install under Debian 10.  It's possible that this is on purpose, and it's (separately) possible that the Debian packagers did this for some reason.  I'm not sure it's a bug but am reporting it as it's an oddity that might warrant looking into.

When I look at sys.path in the IDLE shell, the path includes /usr/bin, which is not there under the normal python prompt.  Since /usr/bin is not a place where python modules usually live, it's a bit strange to find it on the path.  It doesn't seem healthy since it could lead to surprises.  But maybe I'm missing something.

Feel free to close this if the inclusion is intentional.
msg369864 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2020-05-25 09:13
I can't reproduce that:

$ python3.7 -c 'import sys; print (sys.path)'
['', '/usr/lib/python37.zip', '/usr/lib/python3.7', '/usr/lib/python3.7/lib-dynload', '/usr/local/lib/python3.7/dist-packages', '/usr/lib/python3/dist-packages']
msg369868 - (view) Author: paul rubin (phr) Date: 2020-05-25 09:42
Matthias, I get the same result you do when I run python from the shell command line.  I see /usr/bin in the path when I import sys and print sys.path from inside IDLE.  In other words this is an IDLE configuration oddity.  Again I don't know if it's a bug.  It's perplexing though.
msg369876 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2020-05-25 13:51
*Exactly* how are you starting IDLE?  This should only happen if you start IDLE in /usr/bin or edit a file in /usr/bin.  Is there any such thing on Linux/Debian as 'start IDLE from an icon', as on Windows?  If so, is the starting directory part of the icon configuration, as on Windows?
msg369921 - (view) Author: paul rubin (phr) Date: 2020-05-25 20:16
I'm using Debian 10 MATE live install and have been running IDLE by clicking an icon on the top panel, but I just tried running IDLE from the shell prompt in a terminal window, and also see /usr/bin in the path.  In both cases, the output of os.system('pwd').read() is my home directory.  IDLE itself is installed in /usr/bin .
msg369927 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2020-05-25 22:26
'IDLE' is an application implemented by Lib/idlelib.  At least on Windows, application startup executables (like pip.exe, on Windows) are normally installed in <pythondir>/Scripts, at least on Windows.  What, precisely, in 'installed in /usr/bin'?

By 'shell prompt', I presume you mean the $ prompt of bash or older unix shell.  What precisely did you type?  What happens if you start with
$ python3 -m idlelib
?

Unless you add -n to the above, IDLE runs in two processes: the IDLE process that runs the IDLE GUI and the user process that runs user code under the supervision of idlelib/run.py.  Each has its own sys and sys.path.  You are seeing the user process sys.path.

To see how python initially sets sys.python in the user process, before IDLE can possible modify it, edit idlelib.run by (temporarily) adding

print(sys.path, file=sys.__stdout__)

after 'import sys'.  To do this with IDLE, click File => Open module and enter 'idlelib.run'.  In case you mistakenly make IDLE not run, note where the file is and maybe make a backup first.  Then close and start IDLE in your terminal and you should see sys.path printed there.  You may see it twice.
msg370047 - (view) Author: paul rubin (phr) Date: 2020-05-27 05:02
Yes as mentioned I'm running Debian GNU/Linux, not Windows.  By "idle is installed in /usr/bin" I mean that it is an executable shell script stored at /usr/bin/idle .  Yes, shell prompt is the $ prompt to bash.  When I run "python3 -m idlelib", /usr/bin does not appear in sys.path.  "python -m idlelib" attempts to run python2 and I don't have python2 idle installed.  I'll see if I can figure out what's going on with sys.path in the user process.  The explanation about the two processes was helpful.  Thanks.
msg370318 - (view) Author: E. Paine (epaine) * Date: 2020-05-29 15:39
This is simply because the Python interpreter is running from /usr/bin. This is shown if you call:

cp /usr/bin/idle idle
./idle

In this case, the Python interpreter is running from the directory you are in and /usr/bin shouldn't(!) show in the path (at least on my system...)
msg373657 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2020-07-14 21:06
Lib/idlelib contains a startup file 'idle.py' (and 'idle.bat' and 'idle.pyw' on Windows).  IDLE, and I, have no control over the installation of IDLE, including the addition of system-specific auxiliary startup files and entries, with names containing 'idle', outside of /idlelib.  On Windows, there is no addition in pythondir/Scripts.  The 'IDLE' Start menu shortcut run idlelib/idle.pyw.

I believe IDLE's only manipulation of sys.path for the user process is to prepend '' or the the edited file's directory.  In my message above describing a possible experiment, 'sys.python' should be sys.path.  You can keep exploring if you want, but I am closing this for now.
History
Date User Action Args
2020-07-14 21:06:13terry.reedysetstatus: open -> closed
resolution: works for me -> not a bug
messages: + msg373657

stage: resolved
2020-05-29 15:39:50epainesetnosy: + epaine
messages: + msg370318
2020-05-27 05:02:34phrsetmessages: + msg370047
2020-05-25 22:26:50terry.reedysetmessages: + msg369927
2020-05-25 20:16:58phrsetmessages: + msg369921
2020-05-25 13:51:18terry.reedysetnosy: + cheryl.sabella
messages: + msg369876
2020-05-25 09:42:11phrsetmessages: + msg369868
2020-05-25 09:13:04dokosetresolution: works for me
messages: + msg369864
2020-05-22 20:39:02ned.deilysetnosy: + doko
2020-05-22 20:35:21phrcreate