3 ms·

Do you mean there might be a 'pip' command in the local directory that might get called by accident, or do you mean the real python pip command might load a pyt

Do you mean there might be a 'pip' command in the local directory that might get called by accident, or do you mean the real python pip command might load a python module from the local directory by accident?

romanows 4y ago
The second thing. Python includes the current working directory first in the module search path. It leads to the above issue and occasionally some a tricky debugging problem.
- jwilk 4y ago
  If you run a script, such as "pip", sys.path[0] is the script's directory, not cwd: https://docs.python.org/3/using/cmdline.html https://docs.python.org/3/using/cmdline.html > If the script name refers directly to a Python file, the directory containing that file is added to the start of sys.path
  - romanows 4y ago
    You are right! I missed the switch from talking about the `python -m`-style invocation versus the `python <script>`-style invocation. (Should I double down and attribute it to difficulties with how significant whitespace indentation can make it hard to determine the scope (of the comment threading on mobile)? :P)
danudey 4y ago
Windows' cmd.exe is the only shell I'm aware of that (by default) checks the local directory for executables before the actual PATH variable, so I wouldn't consider that a real problem. The 'local directory' one is the actual concern. For example, our CI system for one of our tools runs commands like `pip install -U setuptools`. If we switched it to `python -m pip install -U setuptools`, it would continue to work fine - unless a developer accidentally committed a file called `pip.py` to the root. At that point, Python would try to import `pip.py` as `pip` instead of the actual module pip (because current directory is checked for includes first).
- jjnoakes 4y ago
  Did you reply to the right comment? I was looking for clarification on a comment made when discussing running pip directly, as a full path to the pip executable, and not via "python -m pip ...".

romanows 4y ago

The second thing. Python includes the current working directory first in the module search path. It leads to the above issue and occasionally some a tricky debugging problem.

jwilk 4y ago
If you run a script, such as "pip", sys.path[0] is the script's directory, not cwd: https://docs.python.org/3/using/cmdline.html https://docs.python.org/3/using/cmdline.html > If the script name refers directly to a Python file, the directory containing that file is added to the start of sys.path
- romanows 4y ago
  You are right! I missed the switch from talking about the `python -m`-style invocation versus the `python <script>`-style invocation. (Should I double down and attribute it to difficulties with how significant whitespace indentation can make it hard to determine the scope (of the comment threading on mobile)? :P)

danudey 4y ago

Windows' cmd.exe is the only shell I'm aware of that (by default) checks the local directory for executables before the actual PATH variable, so I wouldn't consider that a real problem. The 'local directory' one is the actual concern. For example, our CI system for one of our tools runs commands like `pip install -U setuptools`. If we switched it to `python -m pip install -U setuptools`, it would continue to work fine - unless a developer accidentally committed a file called `pip.py` to the root. At that point, Python would try to import `pip.py` as `pip` instead of the actual module pip (because current directory is checked for includes first).

jjnoakes 4y ago
Did you reply to the right comment? I was looking for clarification on a comment made when discussing running pip directly, as a full path to the pip executable, and not via "python -m pip ...".